Predictability A deadline is not promised. A deadline is sliced.
Any vendor can say a date in the meeting. What decides whether it holds is how big a chunk that date covers. Here nothing starts without an approved stage document: written deliverable, acceptance criteria, go-live date and price. All four fixed before the first line of code.
ERP integration with the customer portal
- An order created in the ERP shows up in the portal within 60 s
- An integration failure posts an alert to your channel within 2 min
- Reprocessing never duplicates an order already sent
- Mobile app for the portal
- Invoice issuing
approved by you before any development
Deadlines do not slip for lack of effort.
They slip because the date was given over a chunk too big for anyone to see the end of. The four patterns below show up in nearly every project that blew its schedule.
- "Six months" turned into eleven.
- A single date over six months of work is not a commitment, it is a bet. A 2-to-6-week stage fits in the head of whoever estimates it, and when it misses, it misses by days.
- At delivery, what arrived was not what you had in mind.
- Testable acceptance criteria were missing. "Integrate with the ERP" reads differently on each side; "an order shows up in the portal within 60 s" has one reading, and can be checked.
- A small request midway cost three weeks.
- The out-of-scope list was missing. Scope with no edge absorbs everything silently, and the cost only shows up as the date that was missed.
- You only found out about the delay when you asked.
- Short stages ending with something live were missing. A stage that ends in production needs no status report: either it is there or it is not.
From problem to production, one stage at a time.
The first three happen before any code exists. That is where the deadline is bought. After that, it is only execution.
The method, in order
Diagnosis
We go into the operation: who does what, in which system, how long it takes and where it jams. Out comes a plan prioritized by impact, with the annual cost of each bottleneck estimated.
- Conversations with the people who operate, not only who decides
- Process map with real time and volume
- Estimated annual cost per bottleneck
Scope written
Each stage becomes a document: the deliverable, the testable acceptance criteria, what stays out, the go-live date and the price. You read and approve knowing exactly what you get.
- Verifiable criteria, not adjectives
- Explicit list of what stays out
- Risks named before they become delays
Stage approved
Nothing starts without approval. From there, that stage's scope, date and price do not move. Changes go into the next stage, with their own date and price.
- Scope locked on both sides
- No surprise invoice at the end
- You can stop between stages, no penalty
Shipped to production
The stage ends with something live, used by real people in your operation. Validation is real usage, not a slide demo. And acceptance criteria are checked item by item.
- Every stage ships instrumented
- Acceptance checked item by item
- Code and environment are yours from day one
Operation under watch
After go-live the system starts being measured: availability, errors, response time and real usage, in the dashboard that is yours. Evolution follows the same scope, date and price rule.
- Alerts in your channel before the complaint
- Open delivery history
- Maintenance also has scope and price
# stage 2 · ERP ↔ portal integration
**Deliverable:** an order created in the ERP
shows up in the customer portal.
## Acceptance criteria
- new order visible within 60 s
- failure alerts the channel within 2 min
- reprocessing does not duplicate an order
## Real examples
→ order 88214, R$ 4,190 → portal ✓
→ ERP down → alert + queue ✓
→ same order twice → 1 record ✓
## Out of this stage
- mobile app for the portal
- invoice issuing
**Go-live:** 18 business days
**Price:** fixed on approvalThe document This is the paper that buys the deadline.
It is not a legal contract nor technical documentation: it is the page describing one stage in terms both sides can check. Written in plain language, with an example of valid input and of failure. If any sentence allows two readings, it goes back for a rewrite before becoming code.
What is always written
- Deliverable
- what comes to exist at the end of the stage, in one sentence
- Acceptance criteria
- verifiable with a number, not an adjective
- Out of scope
- the edge, written down: it is what stops scope from growing on its own
- Go-live date
- when it goes live, not when it is "done"
- Price
- fixed for the scope written above
- Risks
- what could break the date, said upfront and not after
And when scope changes midway?
It always does. The useful question is not how to avoid it, but where the change lands, and who pays for it. There is one rule, and it applies to both sides.
The change goes into the next stage
The running stage continues as approved, all the way live. The new request becomes the next stage's scope, with its own date and price, and you decide whether it is worth more than what was already queued.
Nothing enters without something leaving
If the change has to happen now, something leaves the stage to make room, and that is said at the time, in writing. Scope that only grows is how a date slips without anyone noticing.
You can stop between stages
No penalty and no hostage-taking: whatever is already live keeps running on your infrastructure, with the code and environment in your name. A long contract is not what keeps a client. Delivery is.
The difference shows up the day something goes wrong.
While everything goes well, the two models are indistinguishable. What separates them is what exists in writing when reality knocks.
- One date covers the whole projectThe date covers one 2-to-6-week stage
- "Done" is the opinion of whoever delivered"Done" is the acceptance criteria checked off
- What stays out was never written downThe edge of the scope is in the document
- A change of mind reopens the whole negotiationA change becomes the next stage, with its own price
- You learn the status by askingYou open the dashboard and see what is live
- Leaving the vendor means starting overCode and environment are yours from day one
What people ask before approving the first stage.
How long until the first production release?
From diagnosis to the first stage live, typically 4 to 10 weeks: 1 to 2 weeks of diagnosis, the scope written within days, and 2 to 6 weeks executing the stage. What stretches that number is almost always access: to systems, to data and to the people who run the process.
Is the stage price actually fixed, or an estimate?
Fixed for the scope written in that stage's document. If something not in it shows up during execution, it does not become a silent change order: it becomes the next stage's scope, with its own price, and you decide whether it goes in. That is why the out-of-scope list matters as much as the in-scope one.
Do I need the project defined before contacting you?
No, and it is rare that anyone does. Most arrive with a pain: a spreadsheet holding the team hostage, a manual process that stalls month-end, a system nobody understands anymore. Diagnosis exists precisely to turn that into prioritized scope, with cost and dates, before any development.
What if a stage misses its date?
You hear about it before the date, not after, and that is the part that changes everything. A short stage shipping to production makes the deviation visible early, while there is still room to cut scope or reshuffle. A delay that only surfaces on the date is a symptom of a stage cut too long, which is our mistake in slicing, not a surprise from reality.
Who owns the code and documentation in the end?
You do, from day one, not at the end. Repository, environment and keys stay in your name, and each stage document is part of the documentation your company keeps afterwards. If Steply ever leaves the picture, the system keeps running where it always ran and another team can pick up where we stopped.
Does this method work for integrating legacy systems?
That is where it pays off most. An old undocumented system is exactly the case where a six-month estimate has no basis. Slicing into short stages turns uncertainty into something discovered early and cheaply: the first stage is usually one read or one write, live, proving the path before committing the rest.
Bring us the process nobody can estimate.
You leave the conversation with the first stage mapped out: what it delivers, what stays out, when it goes live and what it costs. Even if you decide not to move forward, that mapping is yours.