Days 1–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, because 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.
- An honest 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. Where we do continue operating something, we say so explicitly and price it separately, rather than letting you become dependent by accident.
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 weekly demonstration is the whole reporting system
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 onerous — but if any of it is impossible right now, it's 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. This is how knowledge survives the person who had it — which matters more in outsourced engineering than 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 substitution after an engagement is awarded requires your written approval in advance. If someone has to change — illness, resignation — you get notice, a replacement you approve, and a paid overlap period so the handover is real rather than 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 demonstration and we'll fix the fit or end it. Monthly engagements carry thirty days' notice, pods end at a sprint boundary, and the two-week trial carries no notice at all. Nobody has to be locked in for this to be worth doing, and 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 synchronous time, others want none and prefer written updates. We'll tell you honestly 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 — but that's an option, not a dependency we engineer into the work.
Can we speak to a current client?
Yes, and we'll offer one whose engagement is comparable to yours. Several clients have agreed to take reference calls, including one where the engagement ended early — we'd rather you heard that directly than not at all.
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 honestly whether we can help within it.