Product engineering for startups
The constraint on an early-stage product is almost never how fast code can be written. It is how quickly the team can find out whether what they built was the right thing. Every decision below follows from that.
Why adding people does not straightforwardly help
The count is not an argument against hiring. It explains a specific observation: a team of five that adds five more does not double its output, because the coordination between them grows far faster than the headcount does. Past roughly eight people the answer is usually to split into teams that own separate areas and talk through interfaces, rather than to keep growing one team and adding process to hold it together.
For a startup the practical consequence is that a small, senior, cross-functional team almost always beats a larger junior one at this stage, because the work is mostly decisions and decisions do not parallelise well.
Scoping a first release
The most useful discipline is not prioritisation but subtraction. Three tests for whether something belongs in the first release:
- Does it change what you learn?If the release teaches you the same thing without the feature, it is not in the first release.
- Is it expensive to add later?Very little is, and the things that are — the data model, identity, the tenancy boundary — are worth deciding carefully now because changing them later is a migration rather than a feature.
- Would its absence stop someone using the product?Not annoy them. Stop them.
Everything else is a candidate for a later release, and most of it will turn out not to be wanted at all, which is the point.
What is worth doing properly from the start
“Move fast” is often read as permission to skip everything. A small number of things are much cheaper now than later, and the list is shorter than most teams assume:
- The data model.Code is rewritten routinely; data is migrated painfully. Time spent here repays more than anywhere else.
- Authentication and the tenancy boundary.Retrofitting proper separation between customers is one of the genuinely hard rewrites, and it is discovered at the worst moment — during the first enterprise deal.
- Deploying on demand.Not a full pipeline; just the ability to ship a change without ceremony. Everything else about iterating quickly depends on it.
- Knowing what happened.Structured logs and basic error reporting from day one, because the alternative is debugging a customer’s report with no evidence.
Notably absent: comprehensive test coverage of features that may not survive the month, a microservice architecture for a product with no users, and premature optimisation for a scale that has not arrived. Each of those can be added when the need is real, and each is expensive insurance against a risk you do not yet have.
Deciding what to build in-house
The question is whether a component is part of what makes the product distinct. Payments, email delivery, authentication and search are solved problems where buying is almost always right — not because building them is hard, but because maintaining them forever is, and none of it differentiates the product. Build the part customers are actually paying for.
Where this fits
The service is Product Engineering, and the sector context is Startups. Where the constraint is people rather than product direction, see Staff Augmentation and the question that decides between augmentation and a managed service; the infrastructure choice that suits this stage is covered in serverless for startups.
