How we work
Fixed term. Fixed scope. The opposite of staff aug.
We don't bill hourly and we don't go open-ended. Every engagement has a start, an end, and a written definition of done. Most clients come back inside 12 months for a different problem, with a clearer scope.
The four steps
-
Listen
A 60-minute call. We ask the awkward questions, write down what we hear, and figure out if we're actually the right team. If we are, you have a one-page scope in 48 hours.
The first call is a working session, not a pitch. We ask what the system has to do on a bad day, who touches it, what breaks today, and what "done" would mean for the person signing the invoice. We write down what we hear and send it back to you. If we are the right team, that becomes a one-page scope with a fixed fee and the names of the people who will do the work. If we are not, we tell you and suggest who is.
Deliverables
- One-page scope
- Fixed-fee proposal
- Named team
What you get
A written scope you can forward internally, a fixed-fee proposal, and a named team. No open-ended estimate.
-
Discover
A short embedded sprint. We pair with your engineers, write code against a real branch, and end with a working prototype and a written plan you can defend.
Discovery is a short embedded sprint. We pair with your engineers on a real branch of your repository, read the code and the data, and build a working prototype of the hardest part first. The point is to replace assumptions with evidence before the full build is priced in detail. The sprint ends with an architecture diagram, a build plan broken into weekly increments, and a demo of the prototype.
Deliverables
- Working prototype
- Architecture diagram
- Build plan
What you get
A prototype you can click through, a diagram your team can argue with, and a build plan with weekly milestones.
-
Build
A small dedicated team, fixed scope, weekly demos, daily commits to your repo. No status decks. No surprise change orders. The thing gets built.
A small dedicated team builds against the plan. Commits land in your repository every day. Every week there is a demo of working software, not a slide deck. Tests, documentation, and runbooks are written alongside the code, because they are part of the system, not paperwork after it. Scope is fixed; if something new is needed, we re-paper it in writing before anyone starts on it.
Deliverables
- Production system
- Tests, docs, runbooks
- Weekly demo
What you get
A production system with tests, docs, and runbooks, demonstrated weekly, with no surprise change orders.
-
Hand off
An engineer on your team owns the system at the end. We taper off at 50% for two weeks to make that real and stay on standby for 90 days.
Handoff is not a document, it is a person. During the last two weeks we taper to 50% so the internal owner is making the decisions and running the deploys while we are still there to answer questions. After that we stay on standby for 90 days: an on-call playbook, a direct line, and a commitment to respond when something breaks.
Deliverables
- Internal owner
- 90-day standby
- On-call playbook
What you get
An internal owner who has already run the system, a 90-day standby, and an on-call playbook.
Why One Ten Labs
What you get when you hire us, written plainly.
You can read it on most consulting websites, so we'll skip the adjectives. Four commitments, in plain English. We'll defend every one of them in your first call.
-
01
Accountable from start to finish.
One named lead owns every engagement end to end: in your standups, on your pull requests, and on the call when something breaks. You always know whose name is on the work.
One named lead per engagement
-
02
Fixed term. Fixed scope.
A start date, an end date, and a written definition of done. No open-ended bills, no scope creep, no surprise change orders. If the scope changes, we re-paper it.
6-16 weeks, fixed fee
-
03
Consulting plus products.
When we see the same problem three times, we turn the solution into a product. You get the speed of something pre-built and the fit of something custom, whichever your problem calls for.
Build vs. buy, settled
-
04
We hand back the keys.
The goal isn't a perpetual retainer. We taper the last two weeks at 50% so your team takes ownership for real, and we stay on standby for 90 days after.
FAQ
Frequently asked questions
How long does an engagement take?
Most engagements run 6 to 16 weeks from the first call to handoff: a one-page scope within 48 hours of the first call, a 1 to 4 week discovery sprint, a 5 to 14 week build, and a two-week taper at 50% while your team takes ownership.
Do you bill hourly?
No. Every engagement has a fixed fee tied to a written scope with a definition of done. If the scope changes, we re-paper it with you before any extra work starts, so there are no surprise change orders.
What happens if we are not a fit?
We say so on the first call and point you at someone who is. The 60-minute call costs nothing, there is no NDA to sign first, and you leave with a clearer picture of the problem either way.
Who owns the system when you leave?
An engineer on your team. We name that person during discovery, pair with them through the build, taper our time in the last two weeks so the ownership is real, and stay on standby for 90 days after handoff.
Where does the code live?
In your repository from day one. Daily commits, weekly demos, tests, documentation, and runbooks are part of the deliverable, not an add-on.
Can we start with something smaller than a full build?
Yes. The two-week technical strategy and architecture review is a standalone engagement that ends with a written plan you can act on with us or without us.
Start a Project
Tell us what's on your roadmap.
A 60-minute call. We listen. If we're a fit, you have a one-page scope within 48 hours. If not, we'll point you at someone who is. Either way, you leave smarter.
- No NDAs to read, no sales motion
- Reply within 1 business day
- Direct line to the people doing the work