How to Choose a Custom Software Development Company

Choosing a custom software development company is one of those decisions that looks like a procurement exercise and behaves like a hiring decision. You are not buying a finished product off a shelf. You are buying a team's judgement, applied to a problem you have not fully specified yet, over a period long enough that the problem itself will change. That is why comparing quotes line by line tends to mislead. The cheapest proposal is often the one that understood the least. This is a framework for evaluating partners on the things that actually predict whether the project ships. ## Start with the problem, not the technology Before you talk to anyone, write down two paragraphs: what is broken today, and what "fixed" looks like in terms someone in finance would recognise. Not "we need a new portal" but "our operations team re-keys 400 orders a week from email into the ERP, and mistakes there cost us returns." A good partner will push back on that framing, and that is the point. If the first conversation is about frameworks rather than outcomes, you are talking to an order-taker. The vendors worth shortlisting will ask uncomfortable questions about your process before they discuss a stack. > If a company agrees with everything in your brief, they have not read it closely enough. ## The five questions that separate teams ### 1. Who exactly will write the code? Ask for names, seniority and allocation. Agencies commonly sell with senior engineers and deliver with juniors, which is not inherently wrong, juniors have to learn somewhere, but it should be visible and priced accordingly. Ask what happens if your lead engineer leaves mid-project. ### 2. How do you handle a change of scope? Every project changes. What matters is whether the contract treats that as a failure to be penalised or a normal event to be managed. Fixed-price contracts with rigid scope tend to produce defensive engineering: the team builds exactly what was written, even when they can see it is wrong, because deviating costs them money. ### 3. What does handover look like? Ask specifically: at the end of the engagement, what do we receive? The answer should include source code, infrastructure definitions, deployment documentation, and credentials in your own accounts, not theirs. If your production database lives in an agency's cloud account, you do not own your product. ### 4. Show me something that went wrong. The most useful ten minutes of any vendor call. Every real team has shipped a bug that reached production, missed a deadline, or misjudged an estimate. A partner who cannot recall one is either inexperienced or managing your impression rather than telling you the truth. ### 5. How will we know it is working? Good partners propose the measurement alongside the build: error rates, page performance budgets, adoption of the new workflow. Without that, "done" is a matter of opinion and disputes become inevitable. ## Reading a proposal properly A proposal is a writing sample. Read it the way you would read a candidate's cover letter. - Does it restate your problem in their own words? If it copies your brief back to you, nobody senior engaged with it.

• Are the assumptions written down? Every estimate rests on assumptions. Listing them is a sign of experience; hiding them is how change requests get weaponised later.
• Is there a discovery phase? Committing to a fixed price for a full build before any discovery is either padded heavily or destined for a renegotiation.
• Does the timeline include testing, deployment and a support window? Timelines that end at "development complete" are describing half the work. ## Engagement models, briefly Fixed price suits genuinely well-defined work, a migration, an integration with a documented API, a defined set of screens. It is a poor fit for anything exploratory. Time and materials suits evolving scope and gives you the ability to change direction. It requires more involvement from you, and you should expect weekly demos and a burn-down you can actually read. Dedicated team suits ongoing product work where you want continuity and the team accumulates domain knowledge. It is the most expensive per month and usually the cheapest per feature by the second quarter. We cover the trade-offs in more depth in our guide to hiring dedicated developers. ## Warning signs - No questions about your existing systems, data or compliance obligations
• A quote produced in under 24 hours for a multi-month build
• Reluctance to put you in touch with a past client
• Portfolio work they cannot describe in technical detail
• A contract with no exit clause, or one where the code transfers only on final payment of an open-ended sum ## Due diligence that takes an hour Look at a public repository or a live product they built and check the things a demo will not show you: does the site load quickly on a phone, is it accessible with a keyboard, are error states handled. Then ask a past client one question, "what would you do differently next time?", and listen for whether the answer implicates the vendor. ## What this looks like in practice At SignX we run a short paid discovery before any build commitment, because an estimate given without understanding your data model is a guess dressed as a number. The output is a scoped plan, an architecture you own, and a cost range you can take to your board. If it turns out we are the wrong fit, you keep the plan. If you are weighing up partners for a project now, tell us what you're trying to build, we will give you an honest read on scope and cost, including when the answer is that you do not need a custom build at all.