How Saiful Khan builds software: architecture, budgets and outcomes

People usually find Saiful Khan after a rebuild has already gone sideways: checkout falls over at peak, an internal AI assistant nobody trusts, a page inventory quietly deindexing. The common cause is almost never the framework choice — it's that nobody wrote down the constraint before writing code.

So every engagement starts the same way. Two to three weeks of discovery produces one document: the business constraint, the measurement that proves it, and the smallest system that removes it. Only then does architecture get drawn, and only then does anything get built.

The second rule is that budgets are enforced, not aspired to. Latency, error rate and index coverage each get a number, and CI blocks anything that breaks them. It's the difference between a system that degrades quietly and one that tells you before your customers do.

The third rule is handover. Saiful Khan works embedded with existing teams, documents every architectural decision, and leaves the system owned internally. A build that only its author can operate is an unfinished build.