What Hiring a Small Software Firm Looks Like

Hiring a software firm for the first time is uncomfortable in a specific way. You are buying something you cannot fully evaluate, from people whose job is to know more about it than you do, at a price that is hard to compare against anything. Most of the anxiety comes from not knowing what a normal project is supposed to look like.

So here is what a normal one looks like when it is run well, from the first call to the day you own the thing, plus the questions that separate a firm worth hiring from one that will cost you twice.

This is written from the side of a small, engineer-run firm, because that is what we are. But the questions at the end apply to anyone you are thinking of hiring, including us.

The First Call

The first call should be about your problem, not their credentials. A good one spends most of its time on questions like these:

• What is the work that is slow, error-prone, or impossible today?
• Who does that work now, and what do they actually do, step by step?
• Which systems are involved, and which one is the source of truth for what?
• What would have to be true in three months for this to have been worth it?

Pay attention to who is on the call. If the person asking the questions will not be anywhere near the work, everything you say gets translated at least once before an engineer hears it, and something always gets lost. At a small firm, the person on the call should be one of the people who builds it.

A good first call also ends with a few honest possibilities, including "you do not need custom software for this." Sometimes the right answer is an off-the-shelf tool, a better-configured version of something you already pay for, or a spreadsheet with some guard rails. We wrote more about that decision in Custom Software or Off-the-Shelf? How to Decide.

The Scope, in Writing

Before any code is written, you should have a written scope that you understand and agree with. It does not need to be long. It does need to answer six things:

• The problem, in your words, not theirs
• What gets built: the specific screens, integrations, reports, or automations
• What does not get built: the things that came up and were deliberately left out
• What done looks like: how you will both know the work is finished, in terms you can check yourself
• What it depends on: the access, data, decisions, or people the project needs from your side
• Timeline and price, and what would change either one

The line about what does not get built matters more than it looks. Most project disputes are not about bad work. They are about two people who honestly remembered the scope differently. Writing down the exclusions is the cheapest insurance there is.

If a firm will not put a scope in writing until you have signed something, that is worth noticing.

Building in Short Cycles

Software built in one long, silent stretch has a way of arriving finished and wrong. The fix is short cycles: build a small piece, show it to you working, adjust, and repeat.

In practice that means you should see real, working software early, not slides and not mockups of what it will eventually look like, and then on a regular rhythm. Every week or two is typical. Each time, you get to say "yes, that" or "no, the warehouse does it the other way round" while it is still cheap to change.

Short cycles also keep surprises small. If part of the plan turns out to be harder than expected, you hear about it in week two, with options, rather than in week ten, with an invoice.

The Hand-Off

The end of a project is where good firms and cheap ones look the most different. A proper hand-off includes:

• The source code, in a repository you control
• Every account, credential, and hosting setting, in your name
• Documentation that explains what the system does and why it was built that way, written for whoever maintains it next
• A walkthrough with the people who will use it day to day
• A clear answer to "what happens when something breaks?"

The test is simple. Could a different, competent engineer pick this up next year without calling the people who built it? If the answer is no, you do not fully own what you paid for. Nothing should be structured so that you have to keep paying the original firm just to keep using it.

What the Project Needs From You

Software projects take some of your time too, and it helps to know how much before you start. On a well-run project, your side usually involves:

• A few hours at the start, explaining the work and reviewing the written scope
• Someone who can answer questions quickly. Most delays on small projects come from decisions waiting on a busy person, not from the code
• Access to the systems and data involved, arranged early rather than discovered halfway through
• Short, regular reviews of the working software, ideally with the people who will actually use it
• A final check against the definition of done in the scope

None of that is heavy, but none of it can be skipped. A firm that never needs anything from you is either guessing or not building what you need.

Twelve Questions to Ask Any Firm Before You Sign

Bring these to any firm you are considering. The answers matter less than how directly they are given.

1. Who exactly will build this, and will I talk to them directly?
2. Can I see a written scope, including what is out of scope, before I commit?
3. How will we both know when the work is done?
4. How often will I see working software, and what will I be able to do with it?
5. What happens if you find something halfway through that changes the estimate?
6. Is the price fixed, capped, or open-ended, and what makes it change?
7. Who owns the code, the data, and the accounts it all runs on?
8. Where will it be hosted, and what will that cost me every month after you are gone?
9. What documentation will I get at the end, and who is it written for?
10. If this needs changes in a year, can someone else make them?
11. What would make you tell me not to build this?
12. Can I talk to someone you have built something for?

Red Flags

None of these is disqualifying on its own, but each one deserves a follow-up question:

• No written scope, or a scope that is all features and no exclusions
• Everyone you meet works in sales, and the engineers appear only after you sign
• Hourly billing with no cap and no clear definition of done
• Long gaps with nothing to see, because "it will all come together at the end"
• Vague answers about ownership, especially of hosting accounts and source code
• Every problem needs a big build. A firm that never recommends the smaller option is not giving you advice
• Proprietary frameworks or platforms that only they can work in

What This Looks Like With Us

We run projects the way this post describes, because it is the only way we have seen small software projects go well: engineers on the first call, a written scope before any code, working software you can see along the way, and at the end your choice of ongoing support from us or a full hand-off of the code, docs and accounts. You can read more about who you would be working with.

If you have a process that is slower or more manual than it should be, tell us what you are dealing with. We will tell you plainly whether it is worth building, and if it is not, what we would do instead.