Most custom software projects that go sideways don't fail because of bad code. They stall, overrun, or quietly get shelved because the wrong questions — or no questions at all — got asked before anyone wrote a line of it. If you're preparing to commission a build, the questions to ask before building custom software fall into two conversations most buyers never separate: the ones you ask yourself about whether your organization is truly ready, and the ones you ask any partner before you hand them the work.
That order matters. The Standish Group's long-running CHAOS research keeps finding the same thing: software projects miss on time, budget, or scope far more often from unclear requirements and weak planning than from weak engineering. The highest-leverage work happens before the build starts.
This guide gives you both halves of that conversation: a readiness set to ask yourself, a vendor-vetting set to ask your software partner, and the red-flag answers that should make you pause. Our team at Craftware has 20+ years of combined experience building on the Microsoft stack, and the projects that succeed almost always start with the questions below. A copy-ready checklist is near the end.
Questions to Ask Before Building Custom Software: Start Here
Knowing what to ask before building software is most of the battle, and the custom software development questions to ask come in two distinct sets — one for you, one for any vendor. Two principles first:
- Readiness is yours to prove. A good partner can build almost anything, but they can't decide what to build or whether it's worth it. That clarity comes from you.
- Vetting is about de-risking, not interrogating. The vendor questions surface how a partner handles ownership, change, and the moment something goes wrong — exactly when a cheap engagement gets expensive.
Work through Part 1 first. If you can't answer it crisply, you're not ready to brief a vendor.
Part 1: Questions to Ask Yourself Before You Build
These internal-readiness questions shape scope, budget, and whether custom is even the right path. Answer them honestly before you talk to anyone.
What problem are we actually solving — and what does it cost us today?
State the problem in one sentence, without naming a solution. "Billing re-keys every invoice into two systems" is a problem; "we need a dashboard" is a guessed solution. Then price it: hours per week × the loaded cost of the people doing it × 52. A task that quietly eats 15 hours a week costs more than most teams assume — and that number is your ROI baseline once the software ships.
Who actually uses this, day to day?
Not the department — the people. The clerk living in the tool at 4:45 on a Friday matters more than the executive who approved it. Building for the org chart instead of the real users is the top reason finished systems go unused, so name the two or three people whose day this has to improve.
What does success look like in 30 days and 6 months?
Define it in measurable terms up front: "invoice processing drops from three days to same-day," or "we retire two spreadsheets and a manual export." If you can't name the metric, you can't tell whether the project worked — and neither can your vendor.
Is this really a build — or a buy, or a configure?
This is where Microsoft-centric companies save the most money, and it's the most important of the build vs buy questions. Pressure-test the alternatives before committing to custom:
- Is there an off-the-shelf product that already does 80% of this?
- Could Power Apps or the Power Platform cover it as low-code, for a fraction of the cost, if the workflow is simple and single-department?
- Could this be a configuration or extension of Dynamics 365 or Business Central you already license, rather than a net-new app?
The honest answer is often a blend: buy the commodity parts, configure what you already own, and build custom only where you truly differentiate — an answer a single-product vendor can't give you.
Are we ready to invest in the whole cost of ownership?
The build price is a down payment, not the total. Budget the full total cost of ownership (TCO):
- Hosting and infrastructure — typically your Azure subscription.
- Licensing for any Microsoft seats or connectors involved.
- Maintenance and enhancements — many teams plan for roughly 15–20% of the build cost per year to keep software patched and evolving. Treat that as a planning range to size against your own scope, not a fixed rule.
If the annual run-cost isn't budgeted, the project isn't funded — it's half-funded.
Are our people ready for the change?
Adoption is where ROI is won or lost. Who owns rollout, training, and the inevitable "can it also do X?" requests? A technically perfect system nobody adopts returns nothing.
What must work on day one — and what can wait?
Separate the must-haves from the someday list early. A tight minimum viable product (MVP) that ships in weeks and earns trust beats a sprawling wishlist that runs out of budget at 70% complete. Everything you defer is money you keep optional.
How does this connect to the systems we already run?
Very little business software lives alone. Map the integrations up front: your ERP or accounting system, Dynamics 365 or Business Central, your CRM, and any data source the tool must read or update. Integration is the most underestimated part of most builds — surfacing it now prevents the most expensive surprises later.
After launch, who owns it?
When the build is "done," who fixes bugs, applies updates, and makes changes six months on? If the answer is "not sure," decide before you start — unowned software rots.
Part 2: Questions to Ask a Software Development Company
Once you're ready internally, these questions separate a partner from a pair of hands. For each, we've flagged the green-flag answer to listen for; the matching red-flag versions are collected in the table below.
Do we own the source code and IP outright?
The single most important vendor question. You should own the source code, the intellectual property, and the right to take it elsewhere — no strings. Green flag: full source-code and documentation handover, yours whether or not you stay, written into the contract rather than promised on a call.
Who's on the team — dedicated or shared? Named PM? Turnover?
Ask who specifically will do the work, whether they're dedicated or shared across accounts, and who your single point of accountability is. Green flag: a named PM, defined senior developers (not anonymous "resources"), and candor about turnover and knowledge continuity.
What's your process and cadence, and how are scope changes handled?
You're buying a way of working, not just code. Ask about methodology, how often you'll see working software, and — critically — how scope changes get priced. Green flag: predictable check-ins, demos every couple of weeks, and a written change-control process so "one more thing" never becomes an invoice surprise.
How do you price — fixed-price or time-and-materials?
Both models are legitimate; what matters is matching the model to how well-defined your scope is.
| Fixed-price | Time-and-materials (T&M) | |
|---|---|---|
| Best when | Scope is clear and stable | Scope is evolving or discovery-heavy |
| You pay for | An agreed deliverable | Hours worked at agreed rates |
| Overrun risk sits with | The vendor | You — in exchange for flexibility |
| Watch out for | Padding and pricey out-of-scope change orders | Scope creep and open-ended billing |
| Best guardrail | A crystal-clear written spec | A not-to-exceed cap plus regular demos |
Green flag: a clear recommendation for your situation and full transparency about what's included and what triggers extra cost.
Where does our data live, and who controls the Azure environment?
For Microsoft-stack builds, this is the question most buyers forget. Your application and data should run in your own Azure subscription and tenant — not the vendor's — so you control access, security, and continuity if you ever part ways. Green flag: your data stays in your environment, and you can grant or revoke vendor access. That's how we deliver the custom applications we build on Azure: into your subscription, not ours.
Can you prove it — references, relevant work, and partner status?
Ask for callable references, similar-domain case studies, and verifiable credentials. For Microsoft work, Microsoft Partner status signals a firm's certifications and delivery record have been independently validated. Green flag: two or three clients you can actually phone and credentials you can verify.
What happens after launch — support, SLAs, and exit?
Ask about warranty, support tiers, response-time SLAs, and the exit plan: if you part ways, how do the code and knowledge transfer? Green flag: support terms in writing and a documented handover plan — a partner confident in their work plans for your independence, not your lock-in.
Red Flags: What a Bad Answer Sounds Like
Most guides never tell you how to evaluate the answers you get. These are the responses that should give you pause, and why.
| The question | A red-flag answer | Why it should stop you |
|---|---|---|
| Who owns the code and IP? | "We retain the code and license it to you." | You're locked in — unable to leave or hire another team without a rebuild. |
| Dedicated or shared team? | "We'll assign whoever's free," no named contact. | No accountability; your project competes for attention you can't see. |
| How are scope changes handled? | "We'll figure it out as we go." | Every change becomes an unpriced surprise on the next invoice. |
| Fixed-price or T&M? | A number with no written scope or assumptions. | The low quote today becomes change-order billing tomorrow. |
| Where does our data and Azure environment live? | "In our environment — don't worry about it." | You don't control access, security, or your own continuity. |
| Can we call references? | Reluctance, or none relevant to your work. | Unproven track record — or clients who wouldn't vouch. |
| What about post-launch support? | "We'll cross that bridge later." | No plan for the moment something breaks after go-live. |
Your Pre-Build Custom Software Readiness Checklist
Copy or screenshot this custom software readiness checklist — the one we walk clients through. Clear every box on the left before you brief anyone, and get a solid answer to every item on the right before you sign, and you'll have de-risked the project more than most buyers ever do.
Ask yourself (internal readiness):
- [ ] Problem stated in one sentence — and today's cost quantified.
- [ ] Real day-to-day users named.
- [ ] Success metrics set for 30 days and 6 months.
- [ ] Build vs. buy vs. configure compared (Power Apps, Dynamics 365, Business Central).
- [ ] Full TCO funded — build, hosting, licensing, maintenance.
- [ ] Owner assigned for rollout, training, and change management.
- [ ] Day-one MVP separated from the someday list.
- [ ] Every required integration mapped.
- [ ] Post-launch ownership decided.
Ask your partner (vendor vetting):
- [ ] Source code and IP owned outright, in writing.
- [ ] Team named, with a single accountable PM.
- [ ] Methodology, demo cadence, and change-control process understood.
- [ ] Pricing model clear, with cost triggers known.
- [ ] Data and app run in our own Azure subscription and tenant.
- [ ] References callable; Microsoft Partner status verified.
- [ ] Support SLAs and exit/knowledge-transfer plan documented.
A Real-World Example: The Questions That Reshaped a Build
Here's a representative example — a composite of projects we see across Greater Houston, not a single named client — of how these questions change outcomes.
A regional distribution company arrived certain they needed a custom order-and-inventory app to replace a tangle of spreadsheets. We walked Part 1 with them first, and two questions reshaped the project.
Build, buy, or configure? They already licensed Business Central but used barely a third of it. Roughly half the "custom" wishlist was standard Business Central they'd never configured, plus a light Power Apps front end for the warehouse — trimming the custom scope substantially on the spot.
How does this connect to what we run? Mapping integrations early surfaced a dependency on their carrier's shipping API that, left undiscovered, would have derailed the build mid-project. Because it surfaced in week one, we designed for it instead of around it.
The ranges are illustrative, but the pattern is real: the right questions up front routinely shift a meaningful share of "custom" scope into configuration and low-code, then make the genuinely custom part a tighter, cheaper build.
Frequently Asked Questions
What should I ask before building custom software?
Four questions for yourself first: What problem are we solving, and what does it cost today? Who actually uses this? What does success look like in 30 days and 6 months? And is this genuinely a build, or could we buy or configure something we already own?
What questions should I ask a custom software development company?
The non-negotiables: Do we own the source code and IP outright? Who's on the team, and who's accountable? How are scope changes priced? Where do our data and Azure environment live? Can I call references and verify your Microsoft Partner status? And what are the support and exit terms?
How do I know if my project is ready to start?
When you can state the problem in one sentence, name the real users, define measurable success, show the full TCO is funded (not just the build), and list every system it must integrate with. If any are fuzzy, a short scoping exercise saves more than it costs.
Should I build custom or use Power Apps or off-the-shelf instead?
Buy or configure first where you can; build custom where you differentiate. Simple, single-department workflows often fit Power Apps or an existing Dynamics 365 / Business Central configuration at a fraction of custom cost. Reserve custom development for complex, multi-system, or competitively important work with no good off-the-shelf fit.
Who should own the source code and IP for a custom build?
You should — full stop. Insist on complete ownership of the source code, documentation, and IP, written into the contract, so you're free to maintain, extend, or move the software with any team. Vendor-retained code or proprietary frameworks are a lock-in risk to avoid.
Have These Answered for You: Book a Free Consultation
You don't have to work through all of this alone. In a free 30-minute consultation, a senior engineer walks these questions with you and gives you a straight read on whether you're ready and whether custom, low-code, or off-the-shelf actually fits — with honest answers on ownership, pricing, and support, not a sales pitch. We'll bring the formatted pre-build checklist to the conversation. If custom is the answer, the next step is a fixed-fee scoping step: one to two weeks mapping the process as it really runs, after which you leave with a written scope, a design, and a fixed price to build it. You can stop there and take the plan elsewhere. Book your free consultation and get clarity before you commit a dollar to the build.
