How we scope a new engagement at Courtix
What the first two weeks of a Courtix engagement actually look like: discovery, written scope, the choice between fixed-price and time-and-materials, and the deliverables we hand over before any code ships.
Most bad software projects are bad before a single line of code is written. They’re bad because nobody agreed on what was being built, for whom, by when, or what "done" looked like. Scoping is the cheapest time to fix that. Here’s how we do it.
Discovery is a paid week, not a free sales call
Before we agree on price or timeline, we run a short paid discovery, typically one to two weeks. It produces a written artefact: a problem statement, a system sketch, a data-flow diagram, a list of risks and unknowns, and a proposed implementation plan broken into phases.
We charge for this because it’s the work. A discovery done well de-risks six months of build. A discovery skipped shows up later as a change order.
What we ask for upfront
Every engagement starts with the same short list of questions:
- What does success look like in three months, six months, a year?
- Who are the users, and what are they doing today?
- What regulated data is in scope (PII, PHI, PCI, financial records)?
- What systems do we have to integrate with, and who owns them?
- What are the hard constraints (budget, compliance deadline, legacy platform)?
If a prospect can’t answer these, discovery is the place to figure them out. If they can, we move faster.
Fixed-price vs time-and-materials
We offer both, and the choice is driven by how much is unknown:
- Fixed-price works when scope is well understood, requirements are stable, and success criteria are measurable. Typical for API integrations, migrations with a clear target, or well-specified feature builds.
- Time-and-materials works when the problem is exploratory, requirements will evolve, or the team is being embedded into the client’s ongoing roadmap. We cap with weekly burn reports and a soft monthly ceiling.
We push back when a client asks for fixed-price on genuinely exploratory work. That’s how budgets get eaten by change orders.
Deliverables before code
By the end of discovery, the client has in hand:
- A written statement of work with phases, milestones and acceptance criteria.
- An architecture document and data model.
- A threat model for anything handling sensitive data, aligned with our Secure SDLC Policy.
- A staffing plan with named engineers, not a vague "team of four".
- A risk register, with owners.
If any of those are missing, we’re not ready to start. That’s a hard rule.
Why it matters
Enterprise buyers have seen projects run over by 2x, 3x, 10x. They’re not buying optimism. They’re buying a team that will tell them "this is going to cost more than you hoped, and here’s why" before the contract is signed, not after.
Scoping well is the first place we prove we’re that team.