Named Engineers, By the Month, Working Your Roadmap
The same people every month, on your product and nothing else. You set the priorities, we run the team, and the size flexes with 30 days notice instead of a hiring cycle.
- You interview and approve every person
- Flat monthly invoice, no timesheet arguments
- Three months, then month to month
An Engineering Department You Did Not Have to Hire
You are buying capacity rather than an outcome: a fixed number of named people, for a fixed monthly fee, working through a backlog you control. There is no scope document, no change requests, and no negotiation every time you change your mind — you simply reorder the list and the team works down it.
The trade is straightforward. On a fixed-price project we carry the risk that the work is bigger than it looked, and you pay contingency for that. Here you carry that risk, pay no contingency, and get complete freedom over direction. When requirements change often, that is the cheaper side of the trade by a wide margin.
- Same faces every month, not a rotating pool
- Code review, testing and release practice included, not extra
- Cover for illness and holidays is our problem, not a gap in your delivery
- No recruitment fees, equipment, payroll or notice periods to manage
What You Can Put on the Team
Mix and match. Most teams start at two or three people and change shape as the product does.
Backend engineer
APIs, data modelling, integrations, authentication, background jobs, infrastructure and the performance work that decides whether the product survives growth. The first hire on most teams, because almost everything else depends on it.
Frontend engineer
Web applications, dashboards, admin panels and customer-facing interfaces. Responsive behaviour, accessibility and the unglamorous state handling that keeps a complex screen from becoming unmaintainable after six months.
Mobile engineer
iOS, Android, or cross-platform where that is the right call. Includes the work nobody costs for: store submissions, review responses, device-specific bugs, push certificates and OS migration each autumn.
QA engineer
Test plans, regression suites, release verification and automated coverage on the flows that carry money or data. Frequently a half allocation on smaller teams, and the role that pays for itself fastest once a product has real users.
Product designer
Interface design, prototypes, design system maintenance and the user-flow thinking that happens before anything is drawn. Usually a half allocation once the core product exists and the work becomes incremental. See design and prototyping.
Technical lead
Included on every team rather than charged as a separate head. Runs sprints, reviews code, makes architecture calls and is the person you escalate to. On teams of four or more the lead takes a dedicated allocation because the coordination becomes a real job.
Indicative cost is roughly $4,500 to $9,000 per person per month depending on role and seniority, invoiced monthly in advance. Half allocations are priced accordingly. Ranges and what moves them sit on the pricing page.
Getting Bigger and Smaller Without Drama
The reason to rent a team rather than build one is that the size can follow the work instead of the other way around.
Start small and deliberately understaffed
Almost every team we run begins with two people, usually a backend engineer and whichever frontend or mobile specialist the product needs. A small team that is clearly too busy tells you far more about real capacity than a large one that is partly idle, and it is much easier to add than to unwind.
Adding a person takes about two weeks
You ask, we propose candidates from the bench or recruit against your requirements, you interview, and they start. Two weeks is typical when the bench has the right skill, longer for a specialist. The onboarding week is ours: a new engineer is productive from their first sprint because the existing team carries the ramp-up.
Removing a person takes 30 days notice
Per person, not for the whole engagement. Funding gets tight, a phase ends, the mobile work finishes — drop that seat and keep the rest. Before anyone leaves, their work in progress is finished or handed over and what they alone knew is written down, so the reduction does not cost you a hidden month of confusion.
Surge capacity for a known deadline
A launch, a funding demo, a compliance date. We can add a temporary engineer for a defined period on the same notice terms. We will also tell you when adding people would make a deadline later rather than sooner, which is the honest answer more often than anybody likes.
Winding down to a retainer
When the roadmap finally quietens, most teams shrink to a maintenance retainer rather than stopping outright. It keeps somebody familiar with the codebase attached to it, at a fraction of the cost, and makes scaling back up straightforward later.
Who Manages the Team, and How Work Gets Chosen
The short version: you decide what, we decide how and in what order within a sprint.
Your side of the line
- Maintaining a prioritised backlog, even a rough one in a shared document
- Deciding what matters most for the next two weeks
- Answering product questions within a business day so nothing stalls
- Accepting or rejecting completed work at the end of each sprint
- Telling us early when the business direction changes, so we stop building the wrong thing
Our side of the line
- Breaking your priorities into tasks that can actually be estimated
- Assigning work, reviewing every change and keeping quality consistent
- Flagging when a request is far larger than it appears, before it is started
- Managing holidays, illness, cover and continuity without it reaching you
- Raising technical debt as a trade-off with a cost, not as a complaint
Planning call
At the start of each sprint we agree what the next two weeks contain and what is deliberately not in them. Scheduled in your morning, US Eastern.
Daily written update
At the end of every working day: what moved, what is blocked, what needs a decision from you. It arrives while your day is still running.
Demo build
Every two weeks, an installable build rather than a presentation. You use it before you accept it.
Monthly review
What shipped, where the effort went, what is slowing the team down, and what we recommend for the month ahead.
How You Know What You Are Getting
Monthly billing without visibility is how these arrangements go wrong. Everything below is available to you from day one, not on request.
The board and the repository
You have accounts on both. Every task, every commit, every pull request and every review comment is visible to you in real time, in your own organisation. Nothing is staged for your benefit before a meeting.
Where the month went
A monthly breakdown of effort across features, bug fixing, infrastructure and technical debt. When the split looks wrong — too much firefighting, too little new work — that is a conversation worth having, and the report is what starts it.
Direct access to the engineers
A shared channel with the people doing the work, not only an account manager relaying messages. Ask a question, get an answer from whoever actually knows. Most technical misunderstandings die in the first thirty seconds of a direct conversation.
When a Team Beats Fixed Price — and When It Does Not
Choose a dedicated team when
- The roadmap runs past the horizon you can describe in a scope document
- You expect to change direction based on what users do
- You are shipping continuously rather than towards one launch
- Writing a quote for every change has become more work than the changes
- You need engineering capacity but hiring in-house is months away or not affordable yet
- You already have a product with users and the work is now permanent
Choose fixed price instead when
- You can describe the finished thing and mostly want to know the number
- The budget is a hard ceiling set by someone else
- It is a one-off piece of work with a clear end
- You do not have anyone with time to prioritise a backlog every two weeks
- You want the risk of an overrun sitting with us rather than with you
- This is a first version and you need a known cost before committing
A team with nobody to set priorities is the most expensive way to buy software, and we would rather say that before you sign than after. If nobody on your side can own the backlog, fixed price or a fractional CTO will serve you better.
Dedicated Team Questions
What is the minimum engagement?
Three months. The first few weeks go into learning your product and codebase, and neither side gets value from that if it ends immediately. After the initial three months it continues month to month with 30 days notice, and the same notice applies to adding or removing a person rather than ending the whole engagement.
Are the engineers really dedicated to us, or shared across clients?
A full-time engineer works on your product and nothing else, and they are named in the agreement. Some roles are genuinely better part time, particularly QA and design, and those we offer at a half allocation with the split stated openly. What we never do is quietly rotate someone across three accounts while invoicing each one for a full person.
Can we interview the people before they join the team?
Yes, and we encourage it. You meet each proposed engineer, ask whatever you want, review their background and decline anyone who is not right. A team you did not choose is a team you never fully trust, and that mistrust costs more in the long run than a few hours of interviews.
Who manages the team day to day?
A technical lead on our side runs the day-to-day work: assigning tasks, reviewing code, unblocking people and protecting the estimates. You decide what matters most, in a prioritised backlog. The split is deliberate, because deciding what to build next and running a sprint are different jobs and most founders only have time for the first.
What happens if somebody is not working out, or leaves?
Tell us and we replace them, at our cost. The incoming engineer overlaps with the outgoing one for a handover period that you are not billed for, and we carry the ramp-up rather than passing it to you. If one of our people leaves the company, the same process applies for the same reason: continuity is what you are paying a team for rather than a set of freelancers.
How is this different from hiring freelancers directly?
A freelancer is cheaper per hour and that is a real advantage. What you take on with freelancers is the management: finding them, assessing skill you cannot evaluate, covering illness and disappearances, and being the only person who understands how the pieces fit together. A dedicated team moves that work to us, along with code review, testing and continuity when somebody moves on.
Tell Us What the Next Six Months Look Like
We will propose a team shape, name the people and give you a monthly figure — including the smaller team, if that is what the work actually needs.