Days 1 to 3
Understand
A conversation about outcomes, constraints and what already exists, with an engineer, not a salesperson. We want to know what happens if this doesn't get built. That tells us more about priority than any requirements document.
If we are the wrong partner for the work, you hear it here rather than three invoices in. That has happened often enough that some of those conversations have turned into referrals.
What you get
- A 30-45 minute call with the engineer who would lead the work.
- A written summary of what we heard, so you can correct us before we quote.
- A straight read on whether this is a good use of your money.
- No charge, and no obligation to continue.
Week 1
Scope & quote
Milestones, named people, and a written rate, reviewed with you line by line. We would rather spend a week arguing about scope than six months discovering we disagreed about it.
For larger builds this includes a technical proposal: the approach, the risks we can see, and what we would need from you. Nothing starts until you have approved it in writing.
What you get
- A milestone plan with dates and named owners on both sides.
- A written rate: monthly per engineer, or per milestone.
- The risks we can already see, in writing, before you commit.
- Profiles of the actual engineers, whom you may interview.
Week 2 onward
Build
Short sprints, a working demonstration every Friday, written updates daily. Progress stays visible without anyone having to chase it, and problems surface in the demonstration rather than in the final invoice.
Retainer engagements open with a two-week paid trial on real tickets. If it isn't working at the end of it, you stop. No notice period, no exit fee, and you keep everything that was built.
What you get
- A working demonstration every week: software you can use, not slides.
- Daily written updates in your channel, in your timezone.
- Second-engineer review on every pull request before it reaches you.
- Direct access to the engineers, not through an account manager.
Final week
Hand over
Documentation, runbooks and a live walkthrough with whoever takes it on. This is written into the scope rather than sold as an extra once you are already committed.
The measure we hold ourselves to: your team should be able to run and change the system without us. If we keep operating something, we say so up front and price it separately.
What you get
- Architecture and decision records: what we chose, and why.
- Runbooks for deployment, monitoring and the things that break.
- A recorded walkthrough with your team, with questions answered.
- Thirty days of questions answered free after handover.
If there is nothing to show on Friday, we say there is nothing to show.
The Friday demo is the reporting
The other half
What we need
from you.
Engagements go wrong for predictable reasons, and most of them are on this list. None of it is heavy. If any of it is impossible right now, better to know before we start.
One person who can decide
Not a committee. Someone empowered to answer questions within a day, or the sprint stalls waiting.
Access in the first week
Repository, environments, and whatever third-party systems we'll touch. Access delays are the single most common cause of a slow start.
Thirty minutes on Fridays
Someone at the demonstration who can say whether it's right. A demonstration nobody attends is just us talking.
Honesty about constraints
Regulatory limits, an immovable date, a system we can't touch, a political situation. All of it changes the design; none of it is a problem if we know early.
Willingness to hear no
Sometimes the right answer is a smaller scope or a different approach. We'll say so, and you're free to disagree.
A definition of done
What has to be true for this to have worked. If we can't articulate it together in stage one, that's the first thing to fix.
How we build
Standards that
don't get dropped.
These hold whether you're paying for one engineer or a pod of five, and whether the deadline is comfortable or not.
Review before merge
Every pull request is read by a second senior engineer of ours before it reaches your team. You get two engineers' judgement at one engineer's rate, and your reviewers spend less time on things that should never have been proposed.
Tests where they earn their keep
We don't chase coverage numbers. We test the paths that carry money, data or risk, and the ones that have broken before. Where a test would only restate the implementation, we don't write it.
Written decisions
Architectural choices are recorded with their reasoning at the time. That is how knowledge survives the person who had it, which matters more in outsourced engineering than almost anywhere else.
Deployment you can trust
If deploying is frightening, everything else degrades. Releases get batched, batches get risky, and risk makes releases rarer. Fixing the pipeline is usually the first thing we do on inherited systems.
Security as a default, not a phase
Least-privilege access, secrets never in the repository, dependencies monitored. We sign NDAs as standard and arrange background checks on request.
Boring where it counts
Proven technology for the parts that must not fail, so that novelty is spent where it actually differentiates your product. We will talk you out of interesting infrastructure choices.
Questions
The things people
ask before signing.
Answered the way we'd answer them on a call. If yours isn't here, ask it directly.
Will we actually get the engineers we interviewed?
Yes. The engineer you meet is the engineer who does the work, and swapping someone after an engagement is awarded needs your written approval in advance. If someone has to change (illness, resignation) you get notice, a replacement you approve, and a paid overlap so the handover is real, not a calendar invite.
Who owns the code and the intellectual property?
You do, from the first commit. Work happens in your repository under your accounts, not ours. We sign NDAs as standard, work on least-privilege access, and can arrange background checks on request. There is no scenario in which you finish an engagement without full ownership.
What if it isn't working?
Say so at the Friday demo and we'll fix the fit or end it. Monthly work carries thirty days' notice, pods end at a sprint boundary, and the two-week trial has no notice at all. You're not locked in. An engagement that continues only because of an exit clause is bad for both of us.
How do you handle time zones?
We're in India and work with teams across the United States, Europe, the United Kingdom, the Middle East and Asia-Pacific. You choose how much of the day should overlap. Some clients want four hours of live time, others want none and prefer written updates. We'll tell you which one suits the work.
How quickly can someone start?
Engineer profiles within a few days of the first call, and a trial sprint typically starting within two weeks. The first pull request usually lands three to five days into that sprint, assuming access has been granted. Access is almost always the bottleneck, not us.
What happens after the engagement ends?
You get documentation, runbooks and a live walkthrough, all written into the scope. We answer questions free for thirty days after handover. After that, most clients keep us on a small monthly retainer for continuity. That's an option, not a dependency we build in.
Can we speak to a current client?
Yes, and we'll offer one whose work is comparable to yours. Several clients have agreed to take reference calls, including one where the engagement ended early. Better you hear that directly.
Are you cheap?
No. We staff senior engineers only, and we lose on price to agencies that don't. What you get instead is work that doesn't need doing twice, and a team that will tell you when you're about to spend money badly. If budget is the binding constraint, say so early and we'll tell you whether we can help within it.