AI features that survive contact with production
The demo is the easy part. What separates a shipped AI feature from a shelved one is evaluation, fallbacks and a clear notion of failure.
Read article →Every architecture decision is a bet on what your system will need to survive. The trouble is that most teams place that bet by looking at what large companies do, and large companies are solving problems that smaller companies do not have yet.
Start with the constraint that will actually bite
Before comparing services, write down the constraint most likely to hurt you in the next eighteen months. It is rarely raw scale. More often it is one of:
- Team size. Microservices assume enough engineers to own them. A service with no owner is not a service, it is an outage waiting for a calendar slot.
- Deployment frequency. If you ship weekly, elaborate progressive delivery is a cost with no return.
- Data gravity. Where your data lives determines what is cheap and what is painful. This is the decision that is hardest to reverse.
- Compliance surface. Regulated data changes your options and it changes them early.
The modular monolith is underrated
For most teams under about thirty engineers, a well-structured monolith with clear internal module boundaries beats a distributed system. You get transactional integrity, a single deployment, and a debugging story that fits in one person's head. Enforce the boundaries in code review and you keep the option to split later, when you have a concrete reason rather than a hypothetical one.
Distributed systems convert an easy problem, calling a function, into a hard one: calling a function that sometimes does not answer.
Buy the undifferentiated parts
Authentication, payments, email delivery, log aggregation, feature flags. None of these will win you a customer, and all of them will consume a quarter if you build them. Build what makes your product distinctive. Buy the rest, and accept the bill.
Make the reversible decisions quickly
Some choices are cheap to undo: a logging library, a CI provider, a component library. Make those fast and move on. Others are expensive: your primary datastore, your tenancy model, your identity system. Spend real time there, write the decision down, and record what would make you change your mind.
Write it down
A one-page architecture decision record per significant choice (context, options, decision, consequences) is the highest-leverage documentation a team can keep. Two years from now, someone will ask why the system works this way. Without the record, they will guess, and their guess will usually be that you were not thinking.