How We Work
The rigor and transparency of a serious company. The speed and economics of a small operation. This page describes the actual operating framework — not marketing.
Operating Model
ReallySmall is a small team collaborating with AI. That's not a limitation we're working around — it's a deliberate operating model. Small means complete alignment between vision and execution. AI collaboration means the capacity to build and maintain software at a level that would normally require a much larger team.
Every process, every decision, every deployment is documented and auditable. The grounding documents that define ReallySmall's identity, principles, and strategy are the same documents that AI reads at the start of every working session. The documentation is the team.
AI Collaboration
AI is a genuine development partner at ReallySmall. We use it at every layer of the operation — and we're transparent about exactly how.
Architecture & Planning
Claude for architectural reasoning, system design, and strategic thinking. Long-form exploration of ideas, trade-off analysis, and iterative refinement of approaches before any code is written.
Development
Claude Code for implementation. Features that might take weeks are completed in hours. The FurballRescue technical refresh — a rewrite from Blazor to MVC — completed in 58 minutes. AI reads the full codebase context and builds on existing patterns.
Operations
AI-assisted support triage structures inbound requests into actionable GitHub issues. Provisioning notifications, data migration workflows, and email drafting all operate through AI collaboration. Every AI action is reviewed before execution.
Quality Discipline
Being small doesn't mean cutting corners. The discipline is what makes the model work.
Behavior-Driven Testing
Domain actors are identified. Use cases are defined per actor. SpecFlow scenarios are written as human-readable Given/When/Then specifications. Tests run against real databases with real domain logic — no mocks, no test doubles. Every test executes inside a transaction that rolls back on completion, keeping the database pristine.
Architecture Decision Records
Every significant technical decision is documented with context, the decision itself, and its consequences. Why SQLite instead of PostgreSQL. Why MVC instead of Blazor. Why a transactional outbox instead of direct sending. Decisions are traceable to principles and prevent revisiting settled questions without good reason.
Continuous Integration
Every push triggers build and test. A green pipeline is required for merge — no exceptions. Every bug gets a regression test before the fix is written. The test suite is institutional knowledge about correct system behavior.
Full Audit Trail
Client provisioning runs through GitHub Actions with permanent logs. Every email sent is recorded in the transactional outbox. Every syndication upload is tracked. Every deployment is auditable. The system knows what it did and when.
Technology
Simple, familiar, proven, and fully maintainable by a small team with AI. No SignalR. No Blazor. No containers. No orchestration. No database server.
.NET 10
ASP.NET Core MVC with server-rendered Razor views. Stateless HTTP, simple horizontal scaling. Known deeply, not chosen for novelty.
SQLite
One database file per tenant. Full isolation between clients. Backup is a file copy. Scales vertically on a single App Service.
Azure
App Service hosting with vertical scaling path. No containers, no Kubernetes, no orchestration. Simple, reliable, and scales vertically as needed.
GitHub
Code, CI/CD, issue tracking, project boards, and automated provisioning pipelines. Single source of truth for the entire operation.
Sustainable by Design
The architecture scales with near-zero marginal cost per client. Each new tenant is an SQLite file — no additional database servers, no per-client infrastructure provisioning, no compounding complexity.
This is what makes flat pricing sustainable long-term. The economics don't change as the client base grows, so the pricing doesn't either.