Most vendors will tell you they're "agile." In practice that usually means daily standups, a Jira board, and story points, with no real commitment about what ships or when. We don't run projects that way. Every engagement at Fostron goes through the same four phases: Scope, Build, Harden, Operate. Not because it's a nice diagram, but because skipping one of these is how projects actually go wrong.
Scope comes first, and it's written down
Before any code gets written, we turn the problem into a written scope document and an estimate, fixed-price or time-and-materials depending on how well-defined the work is. This takes three to ten days depending on complexity. It also means saying no to ambiguity: if we can't write down what "done" looks like, we haven't scoped it yet.
The failure mode this prevents is familiar to anyone who's worked with a vendor before: a project that technically has "sprints" but no actual agreement on what the final thing looks like, so scope drifts for months and nobody can point to a document that says otherwise.
Build means a demo every week, not a status update
Once scope is agreed, we build against a visible backlog with a working demo every week. Not a slide with percentages on it, an actual demo of running software. If a client can't see progress, we don't consider it progress.
This is also where direct access matters. You're talking to the engineer writing the code, not a project manager relaying your question and getting back to you tomorrow.
Harden is the phase agile theater usually skips
This is the one that gets cut under deadline pressure almost everywhere else: load testing, a security review, and a pass through the edge cases that only show up under real usage. We treat this as a phase with its own deliverables, a load test report, a security checklist, a documented rollback plan, not an afterthought squeezed in before launch.
Skipping this phase is exactly how projects that looked fine in a demo fall over in production. We've seen it happen to other teams' handoffs. We don't build that way.
Operate is a commitment, not a hope
After launch, we stay on with an agreed response time for support and iteration. "We'll be around if you need us" isn't a plan. A defined incident response time and monthly iteration based on actual usage is.
Why this beats ceremony-heavy agile
None of this is a rejection of iterative development, we absolutely build and ship incrementally within the Build phase. What we reject is treating ceremony (standups, retros, story-point estimation theater) as a substitute for the two things that actually matter: a written agreement on what's being built, and a hardening phase before it goes live. Standups don't catch a race condition under load. A load test does.