What you can check about a software firm before you pay one
You are about to spend more on this than on anything else the company has bought. You cannot read the code, so start with the four things you can check.
Talk to us first
Tell us what you are trying to build. You get a conversation that ends in a written scope, and a clear no if we are the wrong firm for it.
What usually goes wrong, in the order it usually goes wrong
None of these start as a technical problem. They start as a judgement problem, and by the time the technical part shows, the money is spent.
Four failures, one cause
You had no way to tell competent work from confident work, so every firm’s page read the same, and you picked on impression. That is what buying in this market looks like when nothing lets you tell competent work from confident work.
- First, the people you met are not the people who write the code. The work moves down a chain you never agreed to, and nobody tells you.
- Second, the technology gets chosen for reasons you cannot evaluate. You find out it was the wrong choice when you try to hire someone to maintain it.
- Third, the dates slip quietly. You hear about it late, usually near the point where a delay costs you a raise, a launch or a customer.
- Fourth, what arrives does less than what was described. The gap is hard to argue about, because nothing was written down precisely enough to argue from.
The alternative you are weighing is one in-house hire, so it is worth sizing properly before you talk to anybody, including us. The BLS records a median annual wage of $135,980 for software developers nationally. That figure is from its May 2025 Occupational Employment and Wage Statistics. Benefits run at 30.1 percent of what a private-sector employer pays across all occupations. That adds $58,444 on top, for $194,424 a year. That is a recurring annual employer cost. It carries no hiring cost inside it, and later years do not get cheaper. It is what established employers large enough to answer a survey are recorded paying. It is not a number anyone has quoted you. That addition and that total are our arithmetic over two published BLS series. BLS publishes neither of those two figures. On top of the money sits a calendar. Ashby’s 2026 Talent Trends Report puts the median technical role at 75 days to fill, against 60 days for a business role on the same definition, across its own customer base. Then the person has to learn your product. Work out what that alternative really costs you before anyone quotes you anything.
Somebody has probably told you that outsourced software gets thrown away and rebuilt inside two years. What is measured is something else. Deloitte’s Global Outsourcing Survey 2024 covered more than 500 global business and technology leaders. Of those, 70 percent said they had brought some previously outsourced scope back in-house over five years. Of that group, 65 percent took back under a quarter of it. The reasons Deloitte publishes are keeping control of service quality, and building capability in-house. Failure is not on the list. Deloitte advises on both sides of this, so read it as their finding rather than as settled fact. The chart below sets two groups Deloitte defined side by side. Deloitte did not measure Atyantik, so the split says nothing about how Atyantik works.
Show data table
| Item | Say outsourced services meet or exceed expectations |
|---|---|
| Using managed or outcome-based delivery | 88% |
| Not using those models | 71% |
How the work is bought tracks with satisfaction more closely than who is doing it.
Four checks
What you can actually check before money moves
Who actually writes the code?
A core team assigned only to your project, with a lead software engineer you talk to directly. No rotation, no context-switching, and no handoff you did not agree to. Ask for the names and ask who else those people are working on this quarter.
Who reviews it, and against what standard?
Every change goes through code review by a senior software engineer before it merges. Architecture decisions are written into the technical requirements specification, so somebody reading the system in three years knows why it is shaped the way it is. Ask whether that document exists, and who writes it.
What happens when the scope moves?
Every change request becomes a change note, with time and effort laid out before approval. Nothing in the build moves on a re-scope you have not explicitly accepted. Ask what goes into a change note, and who has to accept it.
How does something in your head become software, when you do not write code?
We translate before we build. Every requirement document is reviewed with you in plain English before any code is written. Ask how that review runs, and who is in the room.
Those four questions are worth more to you than anything else here, because you can put them to every firm bidding for this work and compare the answers without reading a line of code. Ours are above. Hold us to them, and ask whoever else is quoting for theirs in the same form.
Owning it and being able to use it are two different things
You own the code. That is true and it settles nothing, because a handover can be legally clean and still leave you stuck. The question that decides it is simpler. If we walked away tomorrow, could somebody else pick this up, and how would you know that before you sign? Four things decide it, and you can check all four now.
- From Day 1, every line of code is your IP.
- If you have your own Git hosting, cloud accounts and storage, we work inside them. If you do not, we provision them, set them up, and hand you the keys.
- Documentation starts on Day 1 and stays current: architecture, deployment, pipelines, requirements and change notes.
- You already hold the architecture, deployment and CI/CD documentation. You hold the requirements and specification documents and the change notes. Moving the work in-house or to another partner needs nothing new from us. So far, no client has needed to.
The stack we pick is part of this. Choose something you cannot hire for locally and you have bought a system nobody else can maintain, whoever owns the copyright. Ask any firm bidding for this work which stack they will use and how many people within an hour of you can work in it.
For the technical person you are about to ask
Most founders forward a decision like this to somebody who can read code. Here is everything that person needs, so you do not have to explain it secondhand.
Ask us anything on that list and we will answer it in writing. On request a technical person from our side joins within one business day, and the two of them can go straight at the architecture without either of you translating for us.
Forward this part
Send them this
- The team. A named core team, assigned only to this project, with a lead software engineer available directly. No rotation and no subcontracting you have not agreed to.
- Code review. Code review by a senior software engineer on every change. GitFlow, unit and integration tests, and CI/CD gating every merge.
- Architecture. Architecture decisions written into the technical requirements specification, so the reasoning survives the people.
- Change control. Change notes on every change request, with effort stated before approval. Nothing in the build moves on a re-scope not explicitly accepted.
- Ownership. IP from Day 1. Work happens inside your Git hosting and cloud accounts, or we provision them and hand over the keys.
The work stops being invisible when something arrives that you can read without being technical. Here is what that is, in order. Planning is bounded rather than open-ended, and whatever can start while the deeper planning resolves starts in parallel.
What lands in your hands, stage by stage
01
Discovery
The requirements are written down and reviewed with you, line by line, in plain English.
What you receive
A business requirements document.
02
Specification
The architecture decisions are made, and why each one was made is recorded alongside them.
What you receive
Functional and technical specifications, including the architecture decisions and why each one was made.
03
Build
You see the software running at every sprint review and biweekly demo. Not slides.
What you receive
Working software at every sprint review and biweekly demo.
04
Change
Effort is stated before approval, and nothing in the build moves until you accept it.
What you receive
A change note for every change request.
05
Handover
The documentation is brought current and the accounts the work lives in are handed to you.
What you receive
Architecture, deployment and CI/CD documentation, the change notes, and the keys to the accounts the work lives in.
If a date is going to move, you hear about it in the week the risk emerges, not the week before delivery.
Counted as engagements, not as companies.
One engagement, measured from its start date to today.
Counted as projects delivered, not as engagements.
*Disclaimer: All three are counted from our own engagement records. Several of these engagements belong to clients who came back.
Who should not start this conversation
Worth a conversation
You are funding this personally or from a raise, and it is the largest thing the company will buy.
You have no technical person on your side. That is what the plain English reviews and the business analysis work exist for.
You want the option of taking this in-house later, and you want that written into how it is built rather than promised at the end.
Better somewhere else
You already run a software team and want extra capacity rather than a partner. We do that too. It is a different arrangement, and it starts somewhere else.
What you actually want is how an MVP gets built rather than how to choose who builds it.
You want a number before anyone has looked at what you are building. Here the conversation produces the scope, and the number follows the scope. Where the work allows, the parts that are ready can start while the rest of the plan is refined. If you need the number before that conversation happens, we are the wrong firm.
If one of those is you, say so on the first call and we will point you at somewhere better suited.
Questions we get asked every time
Who owns everything you build, including the code, the cloud and the data?
What if we stop working together? Will we be stuck?
We are not technical. Can we still work with you?
What happens if the scope changes mid-way?
How do you make sure the code is solid rather than duct-taped together?
Will we actually launch something, or get stuck in planning?
How do we stay aligned during the build, and when do we hear bad news?
Can you support us after launch, or is this a one-time engagement?
Start with the four questions
Tell us what you are trying to build and where you are stuck. The first conversation runs on the same four checks: who writes it, who reviews it, what happens when the scope moves, and what you hold if we stop.
Two things can come out of it. Either a written scope you can act on, with or without us, or a clear no with a reason you can use. On request a technical person joins within one business day, so bring whoever is going to ask the hard questions.
- You talk to the lead software engineer, not a ticket queue.
- Your IP, your accounts, from Day 1.