Our Delivery Process

Two weeks, and the price tracks the scope. A greenfield product idea sits at the low end. A fifteen-year-old monolith that needs a code review before anyone can responsibly estimate anything sits at the top.

The core Discovery team is a business analyst, a solution architect, and an engagement manager who spend those two weeks learning enough about your business and your system to give you a plan we can stand behind. A solution architect works through the technical choices with you, designs the system, and makes sure the estimate reflects what it will actually take to build. An engagement manager keeps the whole thing on rails. When the work calls for specialized expertise, we bring in the right domain expert for those sessions instead of pretending the core team knows everything.

We start by talking through the business and the current system with your team. Then we work through what we learned together, agree on the direction, and turn it into an architecture and delivery plan.

By the end, you have enough to move forward without depending on us. Your team, or another vendor, can pick up the requirements, architecture, risks, estimate, and prototype and understand where to go next.

Fixed price for Discovery. Project work is fixed price against an agreed scope. Monthly per engineer for dedicated teams and staff augmentation. Monthly retainer for managed services, sized to the response times you need.

One thing that has changed quite a bit is how much routine implementation work still needs senior engineering time. Charging senior rates for that work is hard to justify, and enterprise buyers know it. Most of the estimate now comes from the parts that still need an experienced engineer to think them through, especially the places where your system, your data, and the way your business actually works do not line up neatly.

In practice that usually means a smaller, more senior team than you’d expect for the scope.

It changes on nearly every project, so the plan is built to absorb it.

We keep releases small on purpose. When something changes, we can usually adjust one part of the plan without making you rework the whole project. We show you what a change will do to the timeline and budget before it becomes part of the plan, so there are no surprises later. Nothing gets added to the scope until you’ve seen the impact on cost and timing and approved the change.

Discovery is usually the easiest engagement to start because the team is small and the work only takes two weeks. Most of the time, we are simply finding the first two-week window that works for everyone. Ask for our next available slot and we’ll give you a start date on the call.

A dedicated team takes longer, and anyone promising a fixed timeline before seeing your stack is guessing. Shortlisting, interviews, and onboarding take time, and a niche stack can extend the process. If your stack involves embedded systems or an unusual data layer, tell us on the first call and we’ll start sourcing that week.

Yes. Many clients do. A client might start with Discovery, stay with us for the first release, and then move to a dedicated team once there is enough ongoing work to keep that team busy. Some end with a Build-Operate-Transfer, with the team moving in-house.

We try to make the change pretty uneventful on your side. The relationship stays the same, the team already knows the product, and we adjust the commercial model and who owns the day-to-day delivery.

The agreement covers ownership of the code and every project artifact from day one.

That includes Discovery. If you decide to take the work to your own team or another vendor afterward, they should be able to understand what we decided, why we decided it, and what needs to happen next.

That’s on us. We employ them, so replacements, vacation coverage, and sick leave are our responsibility.

No formal case required. If the fit feels wrong, we’ll start the replacement while the rest of the team keeps shipping.

Replacing one engineer is usually the easy part. What hurts a project is losing everything that person knew and never wrote down. We’ve taken over enough projects where everyone eventually says, ‘The person who knew that left a while ago.’ After a few of those, you get serious about documenting decisions as you make them. Decisions, business logic, and runbooks stay in your systems, so the project can survive someone’s departure.