If your business has never commissioned custom software, the process can feel risky. You may have heard stories of projects that ran over budget, delivered something nobody used, or left the business dependent on a developer who stopped responding. Those stories are real. But most of them come down to a handful of avoidable mistakes in how the project was briefed, scoped and managed.

Here’s how to approach your first custom software or website project with confidence.

Start with the problem, not the solution

You don’t need a technical specification to begin. In fact, starting with a detailed feature list can lead you astray. Start with the business problem:

  • What’s not working today? Slow quotes, lost enquiries, spreadsheet errors, constant status calls
  • Who is affected? Your team, customers, suppliers
  • What does it cost? Time, mistakes, lost sales, frustration
  • What would “better” look like? Faster, fewer errors, more visibility

A good development partner will help you turn that into a scope.

Write a simple brief

A one- or two-page brief is enough to start useful conversations. Include:

  1. About your business — what you do, who your customers are, how large your team is
  2. The problem — in your own words, with examples
  3. Who will use it — roles, how many people, how technical they are
  4. Current tools — spreadsheets, accounting software, CRM, website platform
  5. Must-haves — what the first release absolutely needs to do
  6. Nice-to-haves — what could come later
  7. Constraints — timeline, budget range, regulatory needs
  8. How you’ll judge success

Being open about your budget range helps a partner recommend a realistic scope rather than guessing.

What to look for in a partner

They ask about your business before your features

The best partners want to understand your customers, process and goals before proposing technology. Be cautious of anyone who quotes a large fixed price after a five-minute conversation.

They’ve built similar things

Ask for examples relevant to your situation: industrial websites, internal systems, integrations with tools like yours. Look at live work where possible. You can see ours in selected work.

They scope in writing

A written proposal should clearly state deliverables, exclusions, timeline, review points, payment milestones and what happens if requirements change.

They talk about running costs

Hosting, domains, third-party services, licences, AI usage and maintenance can all carry ongoing costs. A trustworthy partner identifies them up front.

They hand over ownership

Make sure the contract covers source code, accounts, access and documentation. You should be able to continue with another provider if you ever need to.

They communicate clearly

Especially when working across timezones, agree how and when you’ll communicate, who your contact is and how progress will be shown.

Start with a focused first release

The most reliable way to reduce risk is to keep the first release small. Build the one workflow that solves the biggest problem, launch it, learn from real use and then extend. This approach:

  • Delivers value sooner
  • Limits your initial investment
  • Tests the partnership before larger commitments
  • Produces a better final system, because later features are informed by real use

Red flags

  • Vague proposals without clear deliverables or exclusions
  • No discussion of testing, handover or ongoing costs
  • Reluctance to show previous work or provide references
  • Pressure to sign quickly or pay most of the cost upfront
  • Ownership of code or accounts retained by the developer
  • Promises of guaranteed sales, rankings or results

Your role in the project’s success

A partner can’t succeed alone. Your involvement matters:

  • Name a decision-maker who can answer questions and approve work
  • Make time for reviews at agreed milestones
  • Involve the people who will use the system
  • Provide content and data on schedule
  • Discuss changes openly, understanding they may affect time and cost

How we work

At CodeAssemble, every project starts with understanding the business problem. Your proposal sets out deliverables, exclusions, timeline, review points and milestone-based payments, and the contract covers source handover, access and ownership. You can read about how we work in detail.

You don’t need to be technical to commission good software. You need a clear problem, a focused scope and a partner who listens.

Take the first step

Whether it’s a custom web application, automation or a bespoke website, you can start without a specification. Describe the problem you want to solve, and we’ll help shape the right first step.