Custom software, bought properly.

Cost tracks scope drivers, not line count. A focused internal system with two integrations is a different order of magnitude from a multi-tenant platform with billing, audit logging and an AI layer. We quote after the Audit phase, against a written scope - not before. We publish drivers rather than a price list because a number without scope is marketing, not an estimate.

For a well-scoped first release: 8-16 weeks from kickoff, with usable increments demoed every two weeks. Anything promising production in three weeks is either a prototype relabelled or a template with your logo on it. Anything quoting nine months before first release has not de-risked the hard part early.

Ask whether the process is your differentiator. If competitors could buy the same product and get the same outcome, buy it. If the workflow is how you win - pricing logic, routing, underwriting, fulfilment - own it. Most mature stacks are hybrid: bought commodity, built differentiator, integrated properly.

For short-lived internal tools with simple data, yes. It stops being cheaper the moment you need custom auth, high concurrency, complex domain logic, real test coverage or portability - at which point you pay the rewrite you postponed, plus per-seat licensing in the meantime.

You do, from the first commit. Full IP assignment, work-for-hire on all deliverables, your repository and your cloud accounts from day one, and a documented off-boarding plan - repo transfer, credential rotation, runbook handover - that runs automatically at contract end.

Budget 15-20% of build cost annually for dependency upgrades, security patching, observability and small changes. You can run it with your own team - we hand over runbooks and architecture docs for exactly that - or keep a fractional senior on a light retainer for oversight and incident support.

Usually, and usually you should. The pattern is strangler-fig: put a modern API boundary in front of the legacy system, move one bounded capability at a time behind it, keep both running until the old path is dead. Slower headline, far lower risk than a big-bang rewrite - and you keep shipping the whole time.

We use AI-assisted engineering where it earns its place - scaffolding, tests, migrations, refactors - under senior review, with the same CI gates, code review and test discipline as hand-written work. It compresses the mechanical hours, not the architectural judgement. Every line is reviewed by the engineer whose name is on the pull request.

The Blueprint phase produces a written scope with explicit non-goals, and every change goes through a one-page impact note (cost, timeline, risk) before it enters a sprint. Scope changes are normal; silent scope changes are the problem.