The person who answers your first message is the person who writes the code and the person who picks up afterwards.
I build websites and the search visibility that makes them worth having. I am not an agency and I do not take a project and pass it to somebody else. The person you talk to and the person who writes the code are the same person.
That cuts both ways, so here is the downside first: I cannot take many projects at once, and sometimes that means waiting for a slot. What you get in exchange is that nothing is lost in translation between a salesperson and a developer, because there is no salesperson.
The stack is Next.js and TypeScript on Vercel, with Supabase when a project needs data behind it. You should not have to care about any of that. It is there so your site loads fast, search engines read it correctly, and somebody can still change it in three years.
Every site I ship runs on a system I wrote. One typed schema describes the business, and from it the pages derive their metadata, JSON-LD structured data, sitemap, canonical URLs and hreflang graph. Nothing is hand-written per page.
That sounds like an implementation detail. It is actually the whole argument. Hand- maintained SEO markup is correct on launch day and wrong three content edits later, because nobody remembers to update the structured data when they change a price. If it is derived, it cannot drift — and a fix I make once reaches every page and every client at the same time.
It is covered by an automated test suite, and the rules it enforces came from real mistakes rather than a checklist. One example: a page can now declare which languages it actually exists in, because a sitemap once advertised eight URLs for a site that had two.
All of it is public: the framework is on GitHub along with everything else I have built. You can read the code before you decide whether to trust the description of it.
One thing to know before you open it: the code and comments are written in Turkish. That was a deliberate choice for a codebase whose only maintainer thinks in Turkish, but it does mean the English documentation is where to start — there is about 1,400 lines of it, and the architecture notes explain which trade-offs were made and why.
These are the rules I hold my own tools to. They are not promises about your project — but they explain the instinct behind every decision I will make on it.
Every package you add is code someone else maintains, and one day stops maintaining. This framework has exactly one external dependency across all of its packages. Fewer moving parts is not minimalism for its own sake — it is the difference between a site that still builds in three years and one that does not.
My own tools run without an account and usually without a server, because the moment data leaves the device it becomes something to secure, back up and explain. On client work the same instinct shows up as collecting the minimum: the contact form on this site asks for an email and nothing it does not need.
The framework packages have no build script at all — the TypeScript runs directly. A build step is a thing that can break between you and your working code, and most of the time it buys less than it costs. Your Next.js site does need one; almost nothing else does.
Most of the industry quotes first and shows the work later. I do it the other way around: we talk about scope, you get a preview deployment you can open on your phone, and the fixed price comes after that. You are deciding against something real rather than a portfolio of somebody else’s projects.
Once the number is agreed it holds. If the work grows we discuss it and price the addition — the invoice never grows quietly. And launch is the start of the measurement, not the end of the project: search rankings take months to settle, so the interesting data arrives well after handover.
Side projects, not client work — but both are finished, both are live, and both were built under the constraints above.
To understand the local market properly I wrote a scanner that pulled public data on more than 800 businesses and audited each one: does it have a site, does the site load, is it mobile-usable, is the business claimed on Google, has anyone reviewed it recently. Then it generated an individual report for each.
I mention it because it says more about how I approach a problem than a list of frameworks does. When I did not know something about a market, I built a tool to measure it instead of guessing — and several of my assumptions turned out to be wrong, which was the point.
All three are live, and you can open them side by side to see that the same approach holds at different sizes — and that no template was involved.
The first conversation is free and is not a sales call. If you do not need me, that is what I will tell you.