Beyond ‘Can You Build This?’: The Questions That Get You the Right Thing Built

“Can you build this?”

It’s the question almost every project starts with, and almost always the answer is yes. Modern development can build very nearly anything you can describe. So while the question is fair, it rarely tells you much. The yes is the easy part. What it doesn’t surface is everything that actually determines whether the finished thing solves the problem you came in with, on a budget that makes sense, in a way that still works a year from now.

From the build side of the table, we’ve noticed something about the software project questions that precede the builds that landed well. The ones that delivered real value tended to start with a few other conversations, opened early, before anything was locked. Not because a process demanded it, but because those conversations got the business to a better version of what it actually needed, which isn’t always the thing it first asked for.

You don’t need to think like a developer to have these conversations. That’s our job. These are simply the software project questions worth raising before a build commits, the ones that let a technical partner steer you towards the version that’s worth your money. Think of them less as a checklist and more as the difference between ordering off a menu and telling the kitchen what you’re actually hungry for.

Where does the effort actually go?

Effort rarely concentrates where you’d expect. The feature that sounds impressive, the thing you assume will be the heavy lift, is sometimes straightforward. The detail that seems minor, a particular way data has to sync, an integration with a system you already use, a single workflow that has to behave exactly right, is sometimes where most of the work quietly goes.

Knowing this early changes how you plan. If the headline feature is straightforward and a back-office detail is what’s actually demanding, you get to make a deliberate decision about where the effort goes. The conversation isn’t about trimming the idea down. It’s about seeing clearly where the work really sits, so you can choose what’s worth it to your business rather than finding out after the fact.

What happens when it’s empty, or broken, or slow?

Every product has a happy path, the version in the demo where everything works and the data is perfect. The real value is often in the other paths. What does a customer see before anything loads? What happens when a payment fails, a search returns nothing, or someone arrives on a five-year-old phone with patchy reception?

These aren’t technical afterthoughts. They’re the moments where your customer either keeps going or gives up, and they happen far more often than the demo suggests. Deciding how those moments should feel, early, means they reflect how you want to treat your customers rather than whatever the system does by default.

Where will this actually live?

Software that’s perfect on the screen in a meeting meets a different reality in your customers’ hands. A phone in bright sunlight. An older browser. A warehouse tablet. Office wifi that drops at the worst moment.

Where and how people actually use the thing shapes what’s worth building. A slick feature that depends on fast hardware can frustrate everyone on anything slower. Knowing who uses this, where, and on what, lets us build for your real customers rather than for the ideal conditions of a demo.

What’s the riskiest part, and can we prove it first?

Most projects have one element that’s genuinely unproven, the part nobody can be fully certain about until it’s running. The instinct is often to build the safe, familiar parts first and leave the hard thing for last. That’s usually backwards.

This is what proper scoping is for, and it’s why we’ll often suggest a proof of concept before committing to a full build. A proof of concept is a small, focused test of the single most uncertain part, built early and deliberately, to answer the question everything else depends on. Does this integration actually work the way the vendor’s documentation claims? Will this approach hold up under real load? Can the data even do what the idea assumes?

A few days spent proving the risky bit tells you more than weeks of polishing everything around it, and it does it while there’s still time and budget to change course. Scoping the project honestly up front, then de-risking the hardest part before the full build commits, is the difference between a surprise in week one, when it’s cheap to solve, and a surprise in the final fortnight, when the whole project is resting on it and your options have narrowed to bad ones.

What does this need to talk to?

Very little software lives alone. It usually has to connect to something you already run: your CRM, your accounting system, your booking platform, your stock data. Those connections are often where the genuine complexity sits, and they’re easy to underestimate from the outside because they’re invisible in any mockup.

Naming everything the new thing has to work alongside, early, is one of the most useful things you can do. It’s the difference between a build that slots into how your business already runs and one that creates a second system someone has to reconcile by hand every week.

What’s locked, and what’s flexible?

Most projects have a few things that are truly non-negotiable, the elements that, if they changed, would mean it no longer does the job. They also have parts that feel fixed but aren’t.

Telling us which is which is genuinely valuable. If we know a specific outcome is sacred but the way you get there can flex, we can find the path that protects what matters while saving you money on the parts that don’t. Without that, we’re guessing, and guessing tends to protect the wrong things.

What would you build here, if it were yours?

This is the question we wish came up more often. A good development team isn’t just a pair of hands for hire. The people building your project have usually solved similar problems for other businesses, and often have a view on the version that would serve you best.

Asking it doesn’t mean handing over your decisions. It opens the door to options you might not know exist. Some of the best outcomes we’ve been part of came from a conversation that went “you’ve asked for this, and we can absolutely do it, but there’s a simpler approach that gets you the same result for less,” and the business being glad it asked.

Which software project questions matter most?

There’s no order to these software project questions, and no project that needs all six. They’re not a definitive set, and you’ll have your own that matter more to your situation. The point isn’t this particular list. It’s that the early conversation happens at all, before decisions lock and while changing direction is still cheap.

A good development partner should be raising these conversations anyway, early and unprompted, because helping you get the right thing built, not just a thing, is the actual job.

“Can you build this?” gets you a yes. Questions like these get you the version that solves the real problem, fits the real budget, and still works when a real customer is using it on a bad day with a slow connection.

So bring us the idea, even the one that feels slightly too ambitious. Then let’s have the conversation that’s bigger than “can you build it,” because the answer to that one was always going to be yes.

Simon Paul is a Business Solutions and Technology Specialist at Code Brewery who’s spent 25+ years turning business ideas into software that actually earns its keep. He’s happiest when a first conversation ends with a better idea than the one it started with. Reach out to Simon to talk through what an early conversation might do for your next project.