If you are about to hire a studio or freelancer for a website or a piece of software, the first question is not “how much?” It is “what are we actually building, and who owns it when it is done?” That answer shapes the price, the process, and whether you end up with something useful or something you cannot easily change. The safest next step is to ask a few plain questions before anyone writes a spec.
Start with the problem, not the deliverable
Before you ask for a website, app, portal, or dashboard, ask what problem it needs to solve. A good builder should be able to tell whether the work is really a site, a tool, or something simpler.
A custom website is usually the right fit when the old site is slow, hard to edit, does not fit the business, or does not connect to the tools you already use. Custom software makes more sense when a spreadsheet has become the system, customers keep asking for status, or the same information is being entered in multiple places.
If the answer is vague, keep talking until it is clear. The more specific the problem, the easier it is to decide what should exist and what should not.
Ask who owns the code, files, and accounts
This is one of the most important questions to ask early. You want a clear answer on the code, design files, domain name, hosting, analytics, and any connected accounts.
A sensible setup is one where those things are in your name from the start, not handed over later as a final favor. That makes it easier to move, maintain, or hand the work to someone else if you ever need to.
If ownership is fuzzy, ask for it in writing. If a builder cannot explain handover plainly, that is a warning sign.
Find out how they handle scope
Many bad projects go wrong because nobody agreed on what version one was. A good partner should help you separate what needs to exist now from what can wait.
Ask how they define the first release. Ask what is included, what is not, and what happens when you think of new ideas during the build. This matters whether you are making a new website or a customer portal.
Fixed scope is usually best when the finished thing is clear enough to describe now. Ongoing support is better when the work is live and still changing. If they offer both, ask which one matches your situation and why.
Ask how you will see progress
You should not have to wait until the end to see whether the work is heading in the right direction. Ask when you will see something working, not just a design picture or a status update.
For websites, that might mean a staging link where you can review real pages in the browser. For software, it might mean a running build with real data fields and the first working flows.
This helps you catch problems early, before they become expensive to fix. It also tells you whether the team is building in the open or hiding everything until launch day.
Ask what happens to performance, access, and edge cases
A site or app can look finished and still be weak underneath. Ask how they handle speed, mobile use, keyboard access, and the edge cases that only show up once real people use the thing.
For a website, that means asking about load speed, basic search-readiness, clean page structure, and accessibility. Accessibility means the site is built so more people can use it, including people using screen readers or a keyboard.
For software, ask about roles and permissions, backups, error handling, and what happens when two people edit the same record or a field is left blank. These are not extras. They are part of making the system dependable.
Ask how they work with your existing tools
If your business already uses booking, CRM, inventory, email, or another system, ask whether the new build can connect to it properly. Do not settle for a vague “yes” if the real answer is “only through a widget” or “only if that app is on their list.”
A useful builder should be able to explain which tools can connect, how the data moves, and what happens if one of those tools changes later. If you already have an internal developer or another agency, ask whether they are willing to work alongside them.
The best answer is not always “custom everything.” Sometimes the right move is to keep what already works and only rebuild the part that is holding you back.
A simple checklist for the first conversation
Before you commit, ask these questions: What problem are we solving? What is version one? Who owns the code and accounts? How will we review work as it happens? How will you handle performance, access, and integrations?
If the answers are clear, practical, and specific, you are probably talking to someone worth hiring. If the answers stay broad and slippery, pause and ask for more detail.
The right builder should make the next step easier to understand, not harder. If they cannot do that in the first conversation, they may not be the right fit for the build.