Problem:
Product work often dies between a sketch and a working site. The offer is clear in conversation and invisible on the web, or the opposite: a surface exists, but it cannot carry a new line of work. Legacy stacks stall the launch, and the organization waits on a page that should already be taking conversations.
Agencies that only design leave a handoff. Agencies that only ship leave a site that does not match how the business talks. Either way the thing that goes live is thinner than the brief, and the next iteration is another vendor search. The cost is not the first contract. It is the year spent explaining the product through decks because the site cannot do it.
The same failure shows up inside products. Admin tools, marketing sites, and customer surfaces drift apart. Design tokens and components exist in a slide and not in the repo. We have written about what it takes to define launch before the deadline defines it for you, and about saying no to premature optimization when the next system is not what ships.
Approach:
Carbonology designs and builds products and websites from scratch, or iterates on systems that already exist, so what ships is something the organization can run. The work is a single thread: what the page or product must do, the information architecture that makes that obvious, and a Next.js (or adjacent) implementation that a small team can keep.
We prefer boring, durable choices over a stack that impresses in a kickoff and rusts in a year. Copy is part of the build, not a layer someone pastes on at the end. Accessibility, performance, and the unglamorous SEO basics — one H1, unique titles, pages that render as HTML — are treated as part of shipping, not as a later audit.
When the job is a marketing site, the test is whether a stranger can tell what you do and how to start. Client work like the Experienced Advisory Consultants site and the Armentani Brothers site is that kind of brief. When the job is a product, the test is whether the first useful loop exists in production, not only in a prototype. Contact us if that is the gap.
Deliverables:
- A written brief: audience, offer, constraints, and what launch actually means for this project.
- Information architecture and page-level design that can be implemented without a second interpretation.
- Front-end and full-stack implementation, typically Next.js, with the content model the team will actually edit.
- Design-system and token work when the product needs a shared language across surfaces, not a one-off theme.
- Launch hygiene: metadata, redirects, analytics, and a handoff the existing team can operate.
- Iteration on an existing codebase when a greenfield rebuild would be the wrong expense.
Who it's for:
Teams that need a site or product surface to exist in the world — a services firm replacing a brochure that cannot win work, a founder who has an offer and no URL, or an in-house team that needs a focused build alongside their own roadmap.
We are a small practice, not a staff-augmentation bench. If you need a fifty-person squad, that is a different search. If you need a shippable site or a product slice that a few people can keep, that is the work.
Related:
Define launchBefore you use launch as a deadline, say what it actually means.
Say no to premature optimizationIt's easy as a developer to get carried away with automation. "If only x was built, I wouldn't have to worry about y", is a common trap. Here's how to avoid it.
Mastering product & distributionFirst-time founders focus on product, second-time founders focus on distribution. Can we do both?
Questions:
Yes. We can start from an offer and a domain, or from a repo that already has users. The first week is usually about what has to be true at launch, not about picking a visual theme.
Most public sites and product UIs we ship are Next.js. We will work in an existing stack when that is the responsible choice. We will not introduce a new framework to make the engagement more interesting.
We can do either. The better version of the work is both, because the copy, the routes, and the implementation decide whether the thing is usable. A design-only pass still has to be specific enough to build.
Send the URL if there is one, the offer in a paragraph, and the constraint that matters (date, stack, brand, budget band). We reply from Contact, usually within a day.