How We Work: A Written Ballpark First, Then Working Software Every Week
Every engagement starts with a thirty-minute call with an architect and a written ballpark estimate. From then on you see working software every week, your feedback shapes the next iteration, and the code lives in your repository from day one. The engineers who start the work are the ones who finish it.
What working with us looks like
- 30 min
- scoping call with the architect who would lead the workA written view afterwards, either way
- Weekly
- working software demonstrated, your feedback steers the next iterationOn every engagement
- Day one
- code in a repository you ownDocumentation and tests in scope
From first call to a running system
- Day 1
Scoping call
Thirty minutes with an architect: your system, your constraints, and which offer fits, if any.
- Within a week
Written ballpark
A range with stated assumptions, a validity period, the price model and the expected duration.
- Every week
Delivery
Weekly iterations, daily contact between our engineers and yours, working software at the end of every week. Agreed scope changes are priced before the work starts.
- At the end
Handover or support
Documentation, tests and knowledge transfer are in scope, so the system is yours to run. Or we keep running it on a monthly retainer with SLAs and the same engineers.
The weekly delivery loop
Agree the week
Our engineers and yours agree what the iteration delivers, against your priorities.
Build in your repository
Work lands in your repository, with daily contact, so questions are answered the same day.
Demo working software
At the end of the week you see the software running in a demo.
Your feedback steers the next week
What you say in the demo shapes the next iteration, and problems come up while they are still cheap to fix.
Software development engagement models: scoped project or team extension
| Scoped project | Team extension | |
|---|---|---|
| Who directs the work | We do, against the agreed scope and your priorities | Your engineering leadership; our engineers join your team |
| Price model | Time and materials against a written ballpark range | Monthly fee for the named engineers and agreed roles |
| How it starts | Scoping call, then a written ballpark | Profiles and interviews, then an agreed start date |
| Length | Weeks to months, as the ballpark states | Ongoing, typically long-term |
| Best when | You need an outcome delivered, with one team accountable for it | You have technical direction and a backlog that needs more senior hands |
What stays the same on every engagement
Engineering depth
We build high-volume, long-lived Java systems, with established approaches where they fit and our own where they do not. The people on the first call are the people who write the code, and nothing is subcontracted.
Open communication
We ask for feedback every week, and we raise ideas and problems as soon as we see them, including the awkward ones.
Code and knowledge stay with you
Your repository from day one, documentation and tests in the agreed scope, and a handover plan, so nothing depends on us staying.
The whole lifecycle, or the part you need
We work across analysis and design, implementation, testing, data migration, cloud deployment and support. On some engagements we do all of it; on others we come in for the part your team does not want to own. The case studies show both. Where the boundaries can be drawn, a written ballpark sets the starting point; Team Extension suits a backlog you own and want more senior hands on.
Our clients are in the UK, the US and Western Europe. Poland is one hour ahead of London (CET), so our working day covers UK business hours in full and the morning on the US East Coast. We prefer to start an engagement with a visit in person where that is possible, because it is faster than any number of calls.
What clients ask before they start
Do you work on a fixed price?
For technical due diligence, yes. Delivery is time and materials against a written ballpark with stated assumptions, and agreed scope changes are priced before the work starts, so the number does not drift without you seeing why.
How will we know how the work is going?
You see working software at the end of every week and talk to the engineers daily. There is no status-report layer between you and the people doing the work.
Who owns the code?
Work takes place in repositories you control. The agreement assigns ownership of the delivered work to you and records any third-party licensing requirements.
What happens when the engagement ends?
Documentation, tests and knowledge transfer are part of the agreed scope, so your team can run the system. If you would rather we kept running it, managed support continues with the same engineers under SLAs.
Which engagement model should we choose?
A scoped project when you need an outcome delivered and want one team accountable for it; team extension when you have technical direction and a backlog that needs more senior people. Managed support and technical due diligence have their own models, listed on the services page.
The features implemented have received overwhelmingly positive feedback from end-users. Stratoflow has an incredible technical expertise and a high degree of flexibility when it comes to changing project requirements.
Adam HillChief Technology Officer, Legerity
Book a scoping call
Thirty minutes with an architect, not a salesperson. You leave with a written view of scope, price model and whether we are the right team for it.