Startup website development
I build websites for startups: quick to launch, editable by whoever owns positioning, with technical SEO and AI-search readiness from day one — on a stack you can take over.
100
+Completed projects
Websites, landing pages and SEO projects for businesses in different niches and markets.
15
Years of experience
Hands-on experience in SEO, website development and digital strategy.
17
+Industries covered
From local services and startups to real estate, e-commerce and B2B projects.
3
Working languages
English, Polish and Russian — with content and structure adapted to each market.
How I build it
A stack you'd choose yourself
Next.js with a headless CMS — the same setup this site runs on, in three locales. Nothing proprietary, nothing that only I can maintain, and no platform deciding what's possible later.
Content editable without a deploy
Copy, pages and sections managed in a CMS by whoever owns positioning, so the site changes at the speed the product does. Engineering involvement should be for engineering problems.
Technical SEO and AI-search readiness from day one
Structured data, semantic architecture, Core Web Vitals, and content legible to AI assistants. A new domain has no authority to trade on, so structure is the only early advantage — and it compounds. My own site is the demonstration: a client found me through ChatGPT rather than a search engine.
Fast to launch, designed to change
The first version ships quickly, because being live and iterating beats being perfect and late. What matters is that version two doesn't require starting over.
Code and content you own
Your repository, your CMS, documented decisions. When you hire in-house, the handover is a transfer rather than an archaeology project.
Multiple languages when you're ready for them
Correct locale structure built in from the start, so adding a market later is a content decision rather than a rebuild. I've built multilingual sites whose visitors come from more than twenty countries.
The site has to change as often as the product
Early-stage companies have a website problem that established ones don't: the thing being described keeps moving. Positioning gets rewritten after customer calls, the target segment narrows, the pricing model changes, features that seemed central turn out not to be. A site built to describe the product accurately on launch day is describing something else within a quarter.
That reframes the requirement. The question isn't how good the first version is — it's how cheaply the tenth version happens. Which comes down to two things: who can change the copy, and what the platform allows.
On the first, the answer should be whoever owns positioning, without a deploy and without an engineering ticket. If changing a headline requires a developer, the site drifts out of date quietly, and the drift is invisible until someone external points it out. Content in a CMS solves this completely and costs nothing to build in from the start.
On the second, the usual early decision is a website builder, and at the beginning it's often correct — being live this week beats being ideal next month. It stops being correct at a specific and predictable point: when you need real content structure, technical SEO beyond the basics, or any integration the platform didn't anticipate. By then the site has accumulated links and rankings, and moving means a migration rather than a rebuild. Choosing a stack you'd be comfortable owning avoids that step entirely. The same forward planning applies to language versions — building the structure in from the start costs far less than adding it after the fact.
Search deserves attention earlier than most founders give it, for a reason specific to new companies: a new domain has no authority, so it can't win on strength. Structure is the only thing available early, and it compounds — pages built correctly at launch accumulate, while pages built badly need redoing before they can. That includes readiness for AI assistants, which increasingly answer specific questions with a short list rather than a page of links. My own site is the working demonstration of that: a client found me through ChatGPT rather than a search engine, and everything the assistant repeated back was simply what the site states plainly about itself in structured form.
And then ownership. Startups hire engineers. When yours arrives, the site should be something they can take over — your repository, a stack they recognise, decisions documented. The alternative is a conversation where the first recommendation of your first technical hire is to throw away the site you paid for. A rushed redesign carries the same risk — which is why it's worth planning one in advance.
How the work goes
We agree what the site has to do now
Not in a year — now. Who it's for at this stage, what it has to prove, and which parts you expect to rewrite as you learn.
I design for the current version and the next one
Structure that supports today's positioning without making tomorrow's expensive, with content boundaries drawn where changes are likely.
Build and launch
Next.js and a headless CMS, technical SEO and structured data in from the start, performance work, and language structure ready whether or not you use it yet.
Iterate and hand over
You change copy and pages yourself. When you hire in-house, the handover is a repository and documented decisions rather than a dependency on me.
Frequently asked questions
let's talk
let’s discuss your project goals
Tell me about your task, business goals, and current situation. I’ll review it and suggest the best next steps — clear, realistic, and without obligations.
