How long should a custom build take before you see something real?

You should see something real within the first two to four weeks. It won't be finished, but it should be a page, a screen or a small working piece you can open on your own phone, ideally with your own content in it. If a team can't show you anything you can use until month three, the project is carrying more risk than it needs to.

What counts as something real

Something real is a thing you can use. A home page on a test address that you can open on your phone. A login screen that lets you in and shows your account. An order you can enter into a new system and watch move to the next step.

Plenty of early work is useful without being real in this sense. Mood boards, sitemaps, documents full of wireframes and clickable design prototypes in tools like Figma all help you make decisions. But a prototype is a picture of the product. It can't tell you whether the booking calendar handles your three locations, or whether your old customer data imports cleanly.

Status reports don't count either. "Backend 60 percent complete" tells you nothing you can check for yourself.

If the test address needs a password, make sure you have it, and that it works on your own phone rather than only in the team's office. You should be able to look whenever you like, without asking anyone to set up a demo.

Ask for real content as early as possible, too. Placeholder text and stock photos make every page look tidy, and they hide problems. Your actual service descriptions might be three times longer than the design allowed for, and your real product photos might be a different shape. It's far better to find that out in week three.

Seeing it early saves money and arguments

Every custom build has misunderstandings on both sides. You described the quote process one way and meant something slightly different. The team assumed customers log in with an email address when most of yours use their phone number. Gaps like these are normal, and what matters is when you find them.

In week three, a misunderstanding costs a conversation and a few days of work. In month five, it can mean rebuilding pieces that other parts of the system now depend on, and arguing about who pays for that.

Early working versions also tell you how the team operates. If they promise a first version by a date and deliver it on that date, you've learned something no proposal can show you. If the date slips and nobody mentions it until you ask, you've learned that too, while it's still cheap to change course.

Early versions only help if someone on your side looks at them. Block an hour each week to try whatever is new, and write down what's wrong or missing in plain sentences. If someone else in your business will use the system every day, have them try it as well, because they'll spot different problems from the ones you see. Seeing working pieces also makes money decisions easier, since it's much clearer what to add, what to drop and whether to carry on.

A sensible timeline for most projects

The exact shape depends on what you're building, but a healthy project tends to follow a similar pattern.

The first week or two goes on understanding the problem and agreeing on the plan. That stage should end in something concrete, either a written plan with clear screens and dates, or a first working piece. By the end of the first month, the one thing the product must do well should work on a test address, even if it still looks rough.

After that, you should see new working pieces every week or two, each one something you can try. Each should come with a short note saying what changed and what to test, so you don't spend your hour hunting for it.

For a website, that might mean the home page and one key service page live on a test address by the second or third week, with real text in them. For an app, a working login and the single most important action. For an internal system, one workflow running from start to finish with real data from your business.

Larger projects take longer overall, but the first working piece shouldn't arrive much later. A platform that will take a year to complete still needs something you can use in the first month or so. If the plan says otherwise, ask why, and ask what you could see sooner.

An example timeline

Take a cleaning company with about forty staff that wants a customer portal for booking visits and paying invoices, with roughly four months set aside for the work.

A sensible plan might run like this. By week two, there's a written plan and a clickable outline of the booking screens, agreed with you. By week four, customers can log in on a test address and see their upcoming visits, using real data from last month. Booking and rescheduling work from start to finish by week eight.

Invoices and card payments, connected to the accounting system, follow by week twelve. In the last four weeks, ten real customers use the portal before anyone else sees it, so the first people to find problems are friendly ones. Then it launches.

Compare that with a plan where the first ten weeks go on design and "building the foundations", and the first working screen appears in week eleven. If you discover then that the booking logic doesn't fit how your crews are scheduled, there are five weeks left to fix something that could have been caught in week four.

These dates are only an illustration. What matters is the rhythm: something you can use early, then something new every couple of weeks.

Questions to ask before you sign

Ask each team you're considering the same questions, and listen for specific answers with dates attached:

• When will I first see something working, and what exactly will it be?
• How often will I see progress after that, and where?
• Can I try it on my own phone, with my own data?
• What happens if a date slips, and how will I hear about it?
• Who do I talk to when something looks wrong?

Some uncertainty is honest, especially early on. Even so, a team should be able to give you a date for the first working piece and tell you what it will be.

Ask as well who owns the code, the test address and the accounts the project runs on, and when they become yours. The answer matters most on the day you want to change teams, which is the worst day to start asking.

Warning signs once work starts

Some signals are worth acting on early. Weeks pass and the updates talk about setting up architecture, environments or frameworks, with nothing for you to open. Progress is reported in percentages, and demos happen only on the developer's screen, never on a link you can try yourself. You're told that everything will come together at the end.

Silence is a warning sign too. If a week goes by without an update you can act on, ask for one. A team that's making progress is usually glad to show it.

None of these on its own means the team is bad. Some setup work is real and necessary, and a good team will explain it. But if you reach week four with nothing to try, ask plainly for the date when you will have something, and hold the team to it.

If you're already further in than that, the same approach still works. Ask for the smallest useful piece that can be put in front of you within two weeks, and agree on what it will be in writing. How the team responds to that request will tell you a great deal about the rest of the project.

Where to start

1. Write down the one thing your website, app or system must do well, such as letting a customer book and pay. That's what you should see working first.
2. Ask every team you're considering for a dated plan covering the first six weeks, showing what you'll be able to use at each date.
3. Ask each team to describe what a recent client saw in the second week of a project, and judge whether it was something real.