One-man B2B website design agency. Sites that outlive the tools they were made with.
A B2B site has to survive a rebrand, three marketing hires, and whatever your platform decides to do next. Most don't, and the second rebuild usually costs more than the first, because by then the content, the integrations, and the habits have all grown into it.
A visual language with rules that hold as the site grows, a design system your team can build new pages from, and a stack chosen for whoever has to run it rather than whoever built it. Brand, design, and development. Take all three, or just the part you're missing.
Most brand guidelines break the first time someone builds a website from them
They're made by people who won't be building the site. So the palette fails contrast checks, the display type falls apart at phone sizes, and the whole system covers one beautiful hero layout and says nothing about the other forty pages. The team ends up improvising, and six months later the brand on the site and the brand in the PDF are two different brands.
I decide this knowing I'm the one who has to build it. Every rule gets tested in a browser before it becomes a rule, which is why the brand still looks like itself on page thirty.
Positioning
Where you sit in the market, who you're for, and why someone picks you over the obvious alternative. Written in plain sentences, because every decision downstream gets argued against it.
Messaging and tone of voice
What you say first, what you stop saying, and how it sounds. Includes the site's content priorities, so the page structure follows the message instead of the message getting squeezed into a layout.
Visual direction
Type, color, imagery, and the graphic language holding them together. Chosen and checked on real screens at the sizes people actually use, not on a presentation slide.
Guidelines
Rules specific enough to act on: contrast that passes, type that survives a phone, spacing with real numbers. The test is whether a developer who has never met you can build a new page without guessing.
Most website designs cover the happy path and leave the rest to whoever builds it
So the mockups show three products in a grid that will hold nine, a testimonial from a client with a conveniently short name, and no version of the page where the form fails. The build fills those gaps in whatever way is quickest that afternoon, and the site ends up matching the design in the two places anyone checked.
I design the awkward states before the polish, because I'm the one who has to build the ones that got skipped. Empty, loading, error, and far too much text are all cheaper to settle in a design file than in a component.
Structure before layout
Page order comes from what you need to say and in what order, not from which sections the template happens to include. Layout follows, and it gets easier once the argument is settled.
A component system, not a set of pages
Every screen is assembled from the same parts, so a page nobody designed still looks designed. If your team can build a new one from what already exists and have it look deliberate, the system works.
The states nobody asks for
Empty, loading, error, one item, forty items, and a company name three times longer than the one in the mockup. This is where a site actually looks broken, and it costs almost nothing to decide up front.
Checked in a browser, not a design file
Type sizes, contrast and spacing get confirmed on real screens at the widths people use. A design that only holds together at one width is a picture of a website.
The build is done when your team can ship a page without calling me
Most projects call it done at launch. That's the moment the developer's job gets easy and yours gets hard: every small change becomes a request, the queue grows, and the site slowly drifts back out of step with the company. Handing over something you can actually run is a different target, and it changes what gets built.
So the platform gets picked for whoever has to maintain it, the design system arrives as real components instead of a document, and the parts that are easy to postpone get done during the build: performance, accessibility, and clean HTML that search engines and AI crawlers can read.
Platform, chosen for your team
Webflow or Framer when your team wants to edit visually, and I'm certified in both. Next.js and Sanity when the site needs to do more than a builder allows. I'll tell you which and why on the call, and the reasoning is always the same question: who has to run this in year two.
Content your team controls
A CMS your marketing lead can use without a developer on standby. Preview before publishing, and a content structure that makes sense to the people writing rather than only to the person who built it.
Integrations
Your CRM, newsletter, analytics, and forms wired up so data lands where your team already works. Set up once and documented, so nobody is guessing where a lead went.
Fast and accessible, by default
Performance and accessibility handled during the build rather than patched on after launch. All of it checkable, which is the point: open the site and run the tests yourself.
Fixed-price weekly sprints, so you always know what next week costs
Each sprint has its deliverables agreed before it starts. You see the price up front, you watch the work on a live link, and you carry on only while it's still worth carrying on. Most projects run two to eight sprints.
Intro
Thirty minutes on what you're building and why the current site isn't doing its job. You get a ballpark before we hang up.
Proposal
Project scope, timeline, and price in writing, sprint by sprint, so you know what each week buys.
Sprints
Design and development move together from week one, and you follow along on a live staging link. Small corrections early instead of expensive ones late.
You don't need someone to take orders. You need someone to think with.
Most of the people I work with are founders or marketing leads who already have a rough idea of what the site should do. What they don't have is someone who will argue about it and then go and build it. I'll tell you when I think you're wrong, and you'll see the work every week while it happens rather than at the end.
"Aleksi made a website for my company. The website looks very good and there is clearly a lot of expertise for all situations and problems. He also gave me clear instructions on how to work with the website after it was made, and I always get help right away when I need it. Very satisfied with the service."
Niila Stark
CFO at Net Works Company Oy
"The website for our company was implemented really quickly. Our wishes regarding the appearance were listened to and the end result is really good. Highly recommended!"
Vikke-Werner Lampén
Co-Founder at LLK Sales Oy
The questions that decide it
Everything above is what I do. This is how it actually works, including the parts most people find out about later.
Yes. Sprints are invoiced a week at a time and the site is deployable at the end of each one, so stopping costs you nothing beyond the week you already booked. If week three isn't worth $3,900 to you, don't book it. Most engagements run three to six weeks, but that's an outcome, not a commitment.
Tell me your number, or ask me for mine
Money doesn't scale a project up and down, it selects between different projects. So the useful conversation starts from a number, and it doesn't matter which of us says it first.