[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"blog-post-questions-to-ask-a-software-development-company":3,"blog-post-adjacent-questions-to-ask-a-software-development-company":70},{"id":4,"title":5,"slug":6,"excerpt":7,"cover":8,"coverAlt":12,"datePublished":13,"dateModified":13,"category":14,"author":19,"tags":26,"answerFirst":33,"keyTakeaways":34,"body":40,"faqs":41,"sources":60,"relatedServices":61,"seo":65},"zsdfi10lwzrt6gdkpk8phftm","Questions to Ask a Software Development Company Before You Shortlist","questions-to-ask-a-software-development-company","The questions to ask a software development company before any proposal exists, what a good answer sounds like, the warning signs, and how to check references.",{"url":9,"width":10,"height":11,"alt":12},"https:\u002F\u002Fmedia.drieverse.com\u002Fdrieverse-media\u002Fcms\u002Fquestions_to_ask_a_software_development_company_cover_f434e8b052.jpg",2400,1350,"Five lit gates sorting rows of small pills down to three bright lanes, with the words \"Ask what they turn down.\" and five chips, on choosing a software company.","2026-11-05",{"name":15,"slug":16,"description":17,"seo":18},"Engineering","engineering","Software architecture, code quality and the engineering practice behind the systems we build.",null,{"name":20,"slug":21,"entityType":22,"role":23,"bio":24,"credentials":18,"photo":18,"profiles":25},"DrieVerse Tech","drieverse-tech","organization","Engineering Team","DrieVerse Tech is a software design and engineering studio. Case studies and posts published under this byline reflect the team's collective work, reviewed before publication.",[],[27,29,31],{"name":28,"slug":28},"decision-frameworks",{"name":30,"slug":30},"discovery",{"name":32,"slug":32},"risk-management","Before you shortlist a software development company, ask questions whose answers separate suppliers: what they have built closest to your project and what was hard about it, what work they turn down, who will actually do the work, how you will see progress, how they deliver bad news, what you keep if you part ways, and who looks after the software after launch. Then check one reference yourself, ideally a client whose project hit trouble.",[35,36,37,38,39],"Ask your questions before any proposal exists. They decide who gets your brief, which decides which proposals you end up comparing.","Fewer, sharper questions beat a long checklist. Ask the ones whose answers separate suppliers, and listen for specifics rather than reassurance.","Ask what they turn down and how they deliver bad news. A supplier with a clear answer to both has thought about where projects go wrong.","Ask what you keep if you part ways. A good partner can describe the handover before you have signed anything.","Check one reference yourself, ideally a client whose project hit trouble in the middle. How a supplier behaved then tells you more than any case study.","The questions to ask a software development company are most useful before any proposal exists. Once proposals arrive, you are comparing what each supplier chose to put in front of you. Before that, a few good questions decide who gets your brief at all, and so which proposals you end up choosing between.\n\nMost lists of these questions run to forty items about methodology and tools. You do not need forty. You need the handful whose answers separate one supplier from another, and you need to know what a good answer sounds like. The questions for the later stage, once proposals are on the table, are covered in [comparing software proposals](\u002Fblog\u002Fcomparing-software-proposals).\n\n## How to choose a custom software development company: shortlist first\n\nChoosing a custom software development company works best in two steps. First, a short conversation with each candidate to decide who is worth briefing properly. Second, a proper brief to two or three of them, and a comparison of what comes back. Briefing more than three rarely helps: each one takes real time from you, and from them, to do well.\n\nThe first conversation is where the questions below belong. Ask the same ones of every candidate, take notes in the same order, and compare the answers afterwards rather than the impression each call left.\n\n## Questions to ask a software development company about fit\n\n### What have you built that is closest to this, and what was hard about it?\n\nA good answer is specific: a project that resembles yours in the part that matters, and a difficulty they can describe in detail, with what they did about it. A warning sign is a tour of the portfolio, or \"nothing was particularly hard\". Every real project has a hard part, and a team that remembers it learned from it.\n\n### What kind of work do you turn down?\n\nA supplier that says yes to everything is either very large or not listening. A clear answer, such as a type of project, a technology or a timeline they decline, tells you they know where their judgement is strong. It also makes their yes to your project mean something.\n\n### Who would actually work on this, and can we speak to them before we sign?\n\nThe people on the sales call are not always the people who write the code. Ask who would lead the work day to day, how senior they are, and whether you can talk to them before signing. If the answer is that the team will be assembled after the contract, ask how.\n\n### What will you need from us?\n\nEvery project needs time from the client: answers, decisions, access, content, testing. A good supplier tells you plainly how much, from whom and when. A supplier who says they need very little has either done this many times on very similar work, or has not thought about it yet.\n\n## Questions about how they work\n\n### What happens in the first two weeks?\n\nThis is the most revealing process question, because the answer is concrete. Listen for understanding before building: questions about your users and the work, access to the systems involved, the risky part tested early. Be wary of an answer that starts with design mockups or code before anyone has asked what the first release is for.\n\n### How often will we see working software?\n\nNot a status report: software you can click. A good answer is a regular rhythm, and a place where you can try the latest version yourself. Long stretches with nothing to see are where misunderstandings grow quietly.\n\n### How do you tell a client bad news?\n\nAsk for an example: a deadline that slipped, an estimate that was wrong, a feature that did not work as planned. You are listening for how early they said so, what options they offered, and whether they owned it. Every supplier has bad news eventually. The difference is whether you hear it in week three or in the week of the launch.\n\n### How do you use AI coding tools, and who reviews what they produce?\n\nMost teams now use them, and that is fine. What matters is that a person who understands the code reviews every change, that tests exist for the important flows, and that your data and code are not pasted into tools whose terms you have not seen. A clear, unembarrassed answer is a good sign.\n\n## Questions about ownership and the exit\n\n### If we part ways, what would we walk away with, and how long would handover take?\n\nIt is a strange question to ask at the start, which is exactly why it is useful. A good partner can describe the handover before anything is signed: the code, the accounts, the documentation, the deployment process and the knowledge in people's heads, and roughly how long it takes to pass on. If the answer is vague now, it will not get clearer later. What a full handover should contain is set out in [taking over a software project](\u002Fblog\u002Ftaking-over-a-software-project).\n\n### Will we be able to see the code as it is built?\n\nAccess to the repository from the first week, under an account your business controls, means you can always get a second opinion, and nobody has to hand anything over at the end because you already have it.\n\n## Questions about life after launch\n\n### Who looks after the software once it is live?\n\nAsk what happens in the first weeks after launch, who fixes problems and how quickly, and what ongoing care looks like: updates, security patches, monitoring, backups. Some suppliers do this themselves; some hand it to you or to another team. Either can work, as long as it is decided before launch rather than discovered after it.\n\n## References you can actually check\n\nCase studies and testimonials are written by the supplier. Three things are harder to arrange:\n\n- **Software you can use.** A live product or site they built, which you can open and try today.\n- **A conversation with a client.** Ask for one you can call, and ask that client what they would do differently.\n- **A client whose project went wrong in the middle.** Ask for this one specifically. Every supplier has a project that hit trouble. How they behaved when it did tells you more than a smooth project ever will.\n\nA supplier who will not offer any of the three is telling you something.\n\n## How to hire a software developer for an idea\n\nIf you have an idea rather than a defined project, the questions shift. You are not yet buying a build. You are buying help deciding what to build first.\n\n- **Ask what they would build first to test the idea, and what they would leave out.** A good answer is smaller than you expected. A full feature list in the first conversation is a warning sign.\n- **Ask whether they think the idea needs software at all.** Sometimes a spreadsheet, an existing product or a manual service tests the idea faster. A supplier willing to say so is one you can trust with the build.\n- **Ask how they would work with you while the idea changes.** Ideas move once real users see them, so the way of working matters more than the first estimate. The trade-offs between fixed scope and an ongoing team are set out in [choosing a delivery model](\u002Fblog\u002Fchoosing-a-delivery-model).\n\nA freelancer can be the right choice for a contained piece of work with one clear skill. A company makes more sense when the idea needs several skills at once (design, front end, back end, release, support) and continuity if someone leaves.\n\n## Red flags in the first conversation\n\n- **A price before questions.** A quote before anyone understands the work is a guess with a letterhead.\n- **Yes to everything.** No trade-offs mentioned, no work declined, no risks named.\n- **Nobody technical in the room** when the conversation turns to how it would be built.\n- **Vague ownership.** Unclear answers about the code, the accounts or the exit.\n- **Pressure to sign quickly,** with a discount or a start date that disappears.\n\nNone of these alone rules a supplier out. Two or three together usually should.\n\nOnce your shortlist is down to two or three, send each the same brief; here is [how to write a software project brief](\u002Fblog\u002Fhow-to-write-a-software-project-brief) vendors can quote against. If we are on your list, [book a call](\u002Fbook-a-call) and ask us every question above. We would rather be asked, and the other half of that conversation, what we listen for on our side, is in [what we look for in a discovery call](\u002Fblog\u002Fwhat-we-look-for-in-a-discovery-call).",[42,45,48,51,54,57],{"question":43,"answer":44},"What questions should you ask a software development company?","Ask questions whose answers separate suppliers: what they have built closest to your project and what was hard about it, what work they turn down, who will actually do the work, what happens in the first two weeks, how often you will see working software, how they deliver bad news, what you keep if you part ways, and who looks after the software after launch.",{"question":46,"answer":47},"How do you choose a custom software development company?","In two steps. Hold a short conversation with each candidate and ask everyone the same questions about fit, way of working, ownership and support. Then send a proper brief to the two or three whose answers were most specific, check at least one reference yourself, and compare the proposals that come back on the same rows rather than on their totals.",{"question":49,"answer":50},"How do you hire a software developer for an app idea?","Look for someone who helps you decide what to build first, not someone who builds the whole idea. Ask what they would build to test it and what they would leave out, whether the idea needs software at all yet, and how they would work while the idea changes. A small, honest first step is a better sign than a long feature list.",{"question":52,"answer":53},"What are red flags when hiring a software development company?","A price before anyone has asked questions, agreeing to everything without naming trade-offs or risks, nobody technical in the conversation, vague answers about who owns the code and accounts or what happens if you part ways, and pressure to sign quickly. Any one of these deserves a follow-up question; two or three together usually mean moving on.",{"question":55,"answer":56},"How many software development companies should you shortlist?","Usually two or three for the full brief and proposal. Speak briefly to more if you need to, but a proper brief and proposal take real time from you and from each supplier, and comparing more than three rarely improves the decision. The short first conversations are where you narrow the field.",{"question":58,"answer":59},"Should you ask a software development company for references?","Yes, and check them yourself. Ask for software you can use today, a client you can speak to, and ideally a client whose project ran into trouble in the middle. How a supplier behaved when things went wrong tells you more than a smooth project or a testimonial the supplier wrote.",[],[62,63,64],"software-development","it-consulting","app-development",{"metaTitle":66,"metaDescription":67,"ogImage":68,"canonicalPath":18,"noindex":69},"Questions to Ask a Software Development Company First","The questions to ask a software development company before you shortlist: fit, how they work, ownership, support, references, and the warning signs.",{"url":9,"width":10,"height":11,"alt":12},false,{"prev":71,"next":18},{"id":72,"title":73,"slug":74,"excerpt":75,"cover":76,"coverAlt":78,"datePublished":79,"dateModified":79,"category":80,"author":81,"tags":82},"hul0jom4hfpxph4t1zi6yceq","Why Is App Development So Expensive? What Actually Drives the Cost","why-is-app-development-so-expensive","Why is app development so expensive? Most of the work sits behind the screens. The cost drivers, why quotes differ, and how scoping makes an estimate smaller and firmer.",{"url":77,"width":10,"height":11,"alt":78},"https:\u002F\u002Fmedia.drieverse.com\u002Fdrieverse-media\u002Fcms\u002Fwhy_is_app_development_so_expensive_cover_70e93f5e56.jpg","Thin violet plate on a deep grid block cut away below it, with the words \"Most of an app is not on the screen.\" and six chips, for a post on app costs.","2026-11-03",{"name":15,"slug":16},{"name":20,"slug":21},[83,84,85],{"name":28,"slug":28},{"name":30,"slug":30},{"name":32,"slug":32}]