Start with what you need, not who is available
Before comparing people, write down in a few sentences what the website should do. Present a business and bring calls? Take bookings? Sell products? Run part of your daily work, like records or invoices? Each of these is a different kind of job, and they call for different skills.
A simple presentation site, an online shop and a working system for a practice share a domain name and a browser, and not much else. Knowing which one you need makes every conversation that follows shorter and more honest.
What a portfolio should show
Look for work that is live, not only pictures. Open the sites on your phone. Are they fast? Is it clear what the business does and how to contact it? Do the details hold up when you scroll, tap and go back?
Look for honesty about what each project is. A concept, a demo or a proposal for a redesign is legitimate work and shows how someone thinks, but it is not the same as a launched site that real customers use. In my own portfolio each project is labelled: Omaška is a live system for a private practice, while the psychotherapy website and portal for Dr. Krnetić is presented as a demonstration, not as a launched client site.
If every project in a portfolio looks finished, launched and successful, and none of them can be opened, ask why.
Questions worth asking
Who will actually do the work? In a studio, the person in the sales meeting is not always the person writing the code. That is fine, but you should know who is responsible for what.
How do you work with content? Who writes the texts, who provides photographs, and what happens if they are late? Can I update the site myself afterwards, and how?
What happens after launch? Who fixes something that breaks, how do I reach them, and is that included or agreed separately? What will this site need from me in a year?
What would you not build for me? A good developer will sometimes talk you out of a feature. That is usually a sign they are thinking about your business rather than the size of the job.
Who owns the code, the domain and the accounts
This is the question most people forget and the one that causes the most trouble later. The domain should be registered in your name or your company’s name. The hosting, email and analytics accounts should belong to you, with the developer given access — not the other way round.
The code should be yours too, kept in a repository you can access. If the person who built your site disappears, someone else should be able to continue without starting from zero.
Ask for this in writing before the work starts. It costs nothing to agree on and a great deal to untangle.
Red flags
A fixed price given before anyone has asked what the site should do. It either hides a template that will not fit, or a surprise later.
A promise of first place on Google. Nobody controls search rankings. A developer can build a site that search engines read well — clear titles, descriptions, structure, speed, a sitemap — but the position itself depends on much more than the build.
No access to anything until the final payment, or no access at all after it. Vague answers about where the site is hosted. A portfolio you cannot open. Pressure to decide quickly.
Handover and maintenance
A good handover explains how the project runs, where the key logic lives, how to change the things that change most often, and what to watch after release. It should leave you less dependent, not more.
Maintenance is a separate question from building. Some sites need almost nothing for years. Others — a shop, a booking system, anything with payments or personal data — need regular attention. Agree on it openly, rather than discovering it the day something stops working.
Some collaborations are meant to continue. Golden Standard is ongoing work through Studio Blink, where the identity, website, CMS, B2B platform and partner programmes grow step by step. That only works when both sides know what is included and what comes next.
How to compare two offers
Two offers for “a website” can describe completely different things. Put them side by side and check what each one actually includes: how many pages or screens, who provides the texts and photographs, whether there is a way to edit content, which languages, which integrations, what happens after launch.
Look at what is missing as much as at what is written. If one offer mentions mobile layouts, search basics, a handover and a period of fixes after launch, and the other only says “modern responsive website”, they are not the same job at different prices.
If something is unclear, ask for it to be written in plain words. A developer who can explain the work simply usually understands it well.
Developer, studio or a platform
A template platform can be the right answer for a small business that needs a simple page quickly and will maintain it alone. There is no shame in that, and a good developer will say so.
A freelance developer gives you one person who knows the whole project. A studio gives you more hands and roles. What matters is not the label, but whether the people involved can design, build and explain what they made — and whether they will still be reachable later.
How I work
I design and build websites and applications end to end, and studio work runs through Studio Blink in Banja Luka. Every project in my portfolio carries its real status, so you can see what is live, what is in development and what is a proposal.
My advice is the same as above: keep the domain, accounts and code in your name. Price and timing are agreed once the scope is clear, and a handover should explain how to run the project, where the key logic lives and what to watch after release. If you want, send me what your site should achieve and a site or two you like, and we can start from there.
