Starting every project from scratch is the most expensive line you never see

What hurts an early project is rarely a lack of customers. It's that every customer wants a different thing. The first wants a commerce backend, the second a booking system, the third an internal approval flow — you take all three, and for each one you build the tables, the login, the admin screens from zero. At year end revenue is up, output per person is flat, and the team is exhausted. That isn't building a product; it's piecework.

Custom work isn't bad business — it's often the only real revenue you have early on. The only question that matters is whether the next job gets easier because of this one. If it doesn't, you're paid once for hard work, and your delivery cost climbs in a straight line with every new customer.

Three costs nobody books

• Repeated labour. Login, permissions, file upload, notifications, admin lists, data export — nearly every project needs them. In our own delivery work this shared foundation is typically 30–50% of the effort, so ten projects means writing it ten times.
• Split maintenance. Ten customers, ten branches. A bug you fix on project three has to be fixed nine more times in the others. Fix it and you can't bill for it; leave it and the customer complains. A widely cited figure puts maintenance above 60% of total software lifetime cost, and branches only push that higher.
• Key-person dependency. Only the person who wrote each build understands it, so the team can neither grow nor hand over. One person gets sick and delivery stops.

Reuse isn't designed up front

The usual reaction is "let's make the architecture generic first" — and the team burns two months building abstractions nobody has validated before the first customer ships. That's backwards. Reusable modules grow out of real delivery: when you've built the same thing three times, it's worth extracting. Before the third time, build it the quick way and keep a tally of how often it repeats.

• Run a reuse review after every project — half a day is enough. Sort what you wrote into three buckets: only this client will use it; it could serve someone else with changes; it should have been foundation. The third bucket goes into the core library today, the second waits for its second appearance, the first stays in the client's branch.
• Put custom scope in the contract. State what's a standard capability (no extra charge, upgraded with every release) and what's custom (billed separately, exclusive to that client). Most customers accept the split. What they don't accept is believing they bought a product and receiving a one-off build.
• Track one number: how much of each build is new code. It should fall with every project. Five projects in, if it hasn't moved, you're only selling yourself at a higher rate — not building a bigger business.

At 51kaifa.app, every early-product contract carries a standing section called "standard capabilities vs. client customization," and every spec carries a "reuse" line: which parts of this build move into the shared foundation, reviewed together at acceptance. For a team on a tight budget it's the cheapest investment available — it adds nothing to this project's cost, and it decides whether the next one is any easier.