What We Look For Before Taking On a Custom Build

One of the most useful things I can do early in a project is be honest about fit. Not every brief needs a custom build, and not every business is ready for one yet. That is not a negative judgement. It is just the reality of how good digital work gets delivered. The strongest projects usually start with a real business problem, a person who can move the decision forward, and enough clarity to scope the first stage properly.

When those ingredients are missing, the project often becomes expensive in the wrong ways. Teams jump too early into design. Scope keeps shifting because the core problem has not been framed well enough. Budget conversations stay vague. The build becomes reactive instead of deliberate. That is why I pay close attention to project readiness before I pay attention to the feature list.

The first thing I look for is a genuine business problem

A custom build should solve something that matters operationally or commercially. That might be a website that no longer reflects the business, a portal the client base actually needs, a mobile product for a field team, or an internal workflow that is being held together by spreadsheets and memory. The specific shape can vary, but there needs to be a real reason the work deserves custom attention.

If the main goal is simply to have something new, the project usually struggles. If the goal is tied to a clearer problem, the scope becomes much easier to judge. We can separate what is essential from what is only interesting. We can decide whether the solution should be a stronger website, a platform, an app, or a more operational system. Without that clarity, even a technically good build can miss the mark.

The decision-maker matters more than the size of the company

I would rather start with a mid-sized business that has the right person involved than a larger one where nobody can own the direction. The best projects usually have a person in the room who feels the pain directly and can make progress happen. That might be a founder, an operations lead, a product owner, a general manager, or a technical stakeholder. The title matters less than the ability to move the project forward.

When that person is missing, the process tends to stall. Feedback becomes fragmented. Priorities change depending on who last joined the discussion. Important details emerge too late. That makes scoping harder and delivery weaker. It does not mean a broader stakeholder group is a problem. It means the project still needs a clear centre of gravity.

I look for honesty around budget and timing

Budget and timing do not need to be perfectly defined on day one, but they do need to be discussed honestly. Custom work has a real cost, and that cost is not only about development hours. It also reflects the time needed for structure, judgement, design, technical planning, and careful rollout. If a business wants a complex outcome on a lightweight budget, I would rather say that early than pretend it will somehow work itself out later.

The same applies to timing. Some projects genuinely have urgency. That is fine. But urgency still needs a realistic delivery shape around it. If the required outcome and the time available do not line up, the right next step may be narrowing the first release rather than forcing an unrealistic promise.

Discovery quality usually predicts build quality

I pay a lot of attention to how open the business is to proper scoping. The strongest projects do not jump from a loose conversation straight into build. They spend enough time understanding users, workflow, constraints, roles, integrations, commercial priorities, and what the first useful release should actually include. That does not mean months of consultancy. It means enough structure to make the build worth doing.

In practice, that is often where the biggest value gets created. Once the problem is framed properly, the right solution is usually much clearer. Sometimes the answer is smaller than the original idea. Sometimes it is broader. Either way, the project becomes much more dependable because the decisions are being made on stronger ground.

The relationship also has to make sense

Custom work is rarely a one-click purchase. Even when the scope is tight, the project still depends on trust, responsiveness, and a shared standard for how the work should be carried. I look for whether the client values clarity, wants a proper process, and is willing to make decisions with the same seriousness they expect from the build itself.

That is also why not every project is the right fit, and that is okay. A good no early is better than a messy yes that wastes time for everyone involved. When the fit is strong, the process feels very different. The problem is clearer. The conversation is sharper. The scope gets more honest. The build has a much better chance of producing something the business can actually rely on.

If you are preparing for a custom build, the most useful starting point is not a giant requirements document. It is a clear explanation of the business problem, who needs this solved, what the constraints are, and what success should look like. From there, it becomes much easier to decide whether the right next step is a lighter scoping conversation or a deeper workshop. If that is the stage you are in, the cleanest route is usually through contact, with enough context to make the first discussion worthwhile.