How a website or app gets built

It starts with the problem, not the technology. What should the site or app achieve? Who will use it, and what are they trying to do when they arrive? What already exists — a domain, an old website, a logo, texts, photographs, a spreadsheet someone has been keeping for years? And what has to be ready first?

An example or two of sites you like says more than a long brief. It does not have to be from your field. Sometimes the useful part is the calm pace of a page, sometimes the way a menu is organised, sometimes only a colour. I ask what exactly you like about it, because that is the part we can carry over.

This conversation is also where I say what I would not build. If a simpler solution does the job, it is better to hear that at the start than to discover it after launch.

From that conversation I propose a realistic scope and split it into phases. The first phase is the smallest version that does the main job: for a fishmonger like Ihtis at the Banja Luka city market, that meant a clear route from today’s offer to an order through Viber, designed to work comfortably on a phone.

Larger products grow in steps. Omaška, a live system for a private psychiatric and psychotherapy practice, connects booking, patient records, documents, billing in KM and a patient portal. A product like that is not designed in one sitting; each part is built on the one before it.

Price and timing follow from the scope, so they are agreed after this step rather than guessed before it. A number given before anyone knows what is being built is not a promise, it is a guess.

I can work from an existing design, improve rough sketches or design the interface while building. In practice, most projects mix all three: some screens are clear from the start, others only become clear once the real content is on them.

You see the work early, in a browser and on your own phone, instead of waiting for a finished set of pictures. A picture of a website hides the questions that matter: how long the text really is, how a page behaves on a small screen, what happens when a photograph is missing.

The focus is on clear flows, visual hierarchy and the details that make a product feel finished. When a business has no identity yet, that can be part of the work too — the mark, typography and colour are designed alongside the interface, not handed over separately.

Frontend, backend, database and integrations are built together, as one system. I work mostly with React and Next.js on the web, React Native for mobile, and Node.js with a relational database behind them, but the stack follows the problem rather than the other way round.

Business logic — prices, bookings, permissions, who can see which document — is written so it is clear where it lives and how to change it. That matters more than it sounds: the day a price list or a working hour changes, someone should be able to update it without a developer digging through the whole project.

Integrations are part of the same work: payments, calendars, email, maps, file storage, or an AI model when one is genuinely useful. Each one is a dependency, so each one should earn its place.

Content is the part that most often delays a launch. Texts, photographs, product lists and prices usually live in the heads of the people who run the business, not in a folder ready to hand over.

I help shape it: what a page needs to say, in what order, and how short it can be. Good photographs of the real place, product or people do more than any stock image, and when the product photographs are the weak point, there are ways to make a catalogue look consistent.

If a site will be updated often, it gets a simple way to do that — a CMS or an administration panel — so changes do not depend on me.

A project goes better when nobody has to wonder where it stands. You get a link to the work in progress early, and it is updated as the build moves forward, so you can open it on your own phone whenever you want instead of waiting for a meeting.

Feedback works best when it is specific and collected in one place: this heading is too long, this photograph is the wrong one, a customer would ask this question here. Ten small, clear notes move a project further than one long call where everything is discussed and nothing is written down.

Decisions that change the scope — a new feature, a second language, an integration that was not planned — are named as such when they appear. They are often good ideas; they simply belong to a phase, and it should be clear which one.

Before launch I go through layouts on different screens, the main flows and the common edge cases: an empty basket, a long name, a slow connection, a form sent twice.

I check speed and the basics search engines read: titles, descriptions, headings, image descriptions, a sitemap and the language versions of each page. This is not a separate service added at the end; it is part of building a site properly.

The deployment itself is configured and tested before the domain points to it, so the switch is a quiet moment rather than an event.

A handover covers how the project runs, where the key logic lives and what to watch after release. You should own your domain, hosting accounts and code, and know where each of them is.

Some projects end there. Others continue: Golden Standard, a brand and digital system for three markets, is ongoing work through Studio Blink — identity, website, CMS, a B2B platform, partner programmes and a document studio, developed step by step.

The first weeks after launch are the most honest test. Real visitors find the questions nobody thought of, and the site should be adjusted to what they actually do.

What you do and for whom, and what the site should lead a visitor to do: call, book, order, write. One or two websites you like and one you do not.

The texts and photographs you already have, even if they are rough, and access to the domain if one exists. With that, the first conversation can go straight to the decisions that matter.