Custom CMS Development
Description
Once the design is approved, we build the actual site. Not a page-builder theme with the logo swapped. You get a codebase another developer can maintain and a CMS your team can use to update content.
We pick the CMS from the project, not from a stack we are trying to sell:
- Smaller publishing sites and tight budgets: a Git-based CMS such as Sveltia — no server database, content lives in the repo, hosting can stay free. We used this on BSquare.
- Structured, multilingual, or growing products: Payload CMS with Next.js. Collections, relationships, localized fields, and an admin your editors can actually use. This is what Namayandegi Yab and the current Bscenius site run on.
- WordPress, only when it is the honest fit — existing content, a team already trained on it, or a constraint we should not fight.
The frontend is not tightly coupled to the CMS. We use TypeScript types and a mapping layer to keep the interface separate from the CMS's data structure. That is why we can design the UI before the backend exists, and why swapping a data source later does not mean rewriting the site. The method is public in From type to production data.
Training is part of delivery. After payment, the code is yours. Ongoing support is available if you'd like us to help maintain the site after launch.
What's included
- Production codebaseNext.js, TypeScript, real components. Not a locked page builder. Readable enough that another developer can continue.
- A CMS that fits your budget and needsGit-based for lean sites. Payload for structured, multilingual, or expanding products. WordPress when it is the right call.
- Editor trainingWe sit with whoever will actually publish — not a generic admin tour — until they can ship a page without us.
- Full ownership after paymentRepo, CMS, and the work. We are not a hostage-hosting company.
The challenge
Most business sites are slow, hard to update, and do not match how the company actually talks — because they were assembled from a template or a builder nobody on the team wants to open.
We treat the website as a product: named goals, a CMS that matches how you work, and an owner on our side until handoff. You should not need us to change a title, add a service, or publish a case study.
What we do
- Build for real ownershipOpen-source foundations. You can leave. The site should still run.
- Match the CMS to the jobA two-person studio site does not need the same stack as a directory with relationships and a future marketplace.
- Document the architectureThe same patterns we use internally are written in [Docs](/docs). You are not buying a black box.
Our process
- 01
Foundation
CMS, collections, and the TypeScript contract the UI already expects. Media sizes, locales, SEO fields.
- 02
Integrating real content into the approved designs
Approved design wired to live data. Empty states and fallbacks included — editors will leave fields blank.
- 03
Training
How to publish content, edit SEO fields, and avoid breaking the site. Written notes plus a walkthrough.
- 04
Handoff
Repo access, environments, and the option of a support period. You can also take it and not look back.
Why choose us
You are not locked to us
Next.js and Payload (or Git-based CMS) are standard tools. Another competent developer can pick this up.
The people who plan your project build it
Two-person team. Your project isn't a training exercise for a junior developer.
Fixed scope, fixed price
The agreed price covers the agreed scope. If you need new features, we'll discuss the additional work and cost before proceeding.
Frequently asked questions
The one the project can afford and maintain. Git-based (Sveltia) for lean sites. Payload for structured and multilingual work. WordPress when it is already the right ecosystem. We do not force Payload onto a five-page brochure.