Design and layout system
A reusable set of sections, type scale and spacing rules rather than a folder of one-off page designs, so adding a page later costs hours instead of a new project.
Build & Measure
Front-ends built to convert.
Semantic HTML, no framework you did not ask for, and a performance budget written into the contract. The site is the last thing a buyer touches before deciding, and it is the cheapest part of the funnel to improve.
- Performance budget
- LCP under 1.2 s
- Accessibility standard
- WCAG 2.2 level AA
- Typical build window
- Six to ten weeks
- Handover
- Full source, no lock-in
What the engagement covers
From layout system to instrumented launch.
A build is not finished when it looks right. It is finished when it is fast on a mid-range phone, usable with a keyboard, editable by your team and reporting into your analytics correctly.
Semantic front-end build
Correct heading structure, landmark elements and form labelling. This is what makes a site readable to assistive technology and to a search crawler at the same time.
Performance budget enforcement
A page weight and timing limit set at kickoff and checked before every deploy. Anything that breaches it does not ship until it is fixed or the budget is formally changed.
Headless CMS integration
Editing for the content your team genuinely changes, with the structural parts locked. Unrestricted page builders are how fast sites become slow within six months.
Conversion instrumentation
Events specified and implemented as part of the build, not retrofitted afterwards. Every form, call to action and funnel step is measurable from the first deploy.
Handover and documentation
Full repository access, a written architecture note and a recorded walkthrough for your team. You can take the site to any developer, including one who is not us.
Why this works
Four engineering choices, made before the first line.
Most slow, inaccessible websites were not built badly. They were built without limits, and limits are almost impossible to add retrospectively.
-
A performance budget only works if it can fail the build
Everyone agrees the site should be fast until a marketing tag needs adding in week nine. We set numeric limits at kickoff and check them before deploy, so the conversation happens while there is still time to make a choice rather than after launch.
-
Accessibility costs almost nothing before the build
Semantic markup, focus states and colour contrast decided during design add days. Retrofitting them into a finished site regularly costs more than the original build, and in the EU it is increasingly a compliance requirement rather than a preference.
-
No framework you did not ask for
A marketing site rarely needs a JavaScript framework, and shipping one costs load time, a build pipeline and a dependency chain someone has to maintain for years. Where an application genuinely needs one we will use it and say why. The default is not the answer.
-
Instrumented from the first deploy
Tracking added months later never matches what the design intended, because nobody remembers which button was the primary action. Events are written into the specification alongside the layout, which is why the reporting is usable on day one.
What you get
Standards we accept in the contract.
These are verified before launch on real devices, not on a synthetic score from a fast connection. The test results form part of the handover pack.
1.2 s
Largest contentful paint
Contractual performance budget tested on a mid-range Android device over a throttled connection, on every template rather than only the homepage.
AA
WCAG 2.2 conformance
Audited with keyboard-only and screen reader passes before launch, with the findings and fixes documented.
100%
Source code handed over
No proprietary builder, no licence tied to us, no hosting you cannot leave. The repository is yours from the first commit.
30 days
Post-launch support
Included as standard. Anything that behaves differently from the agreed specification is fixed at no cost, not quoted as a change request.
The detail
Process, team and stack.
Builds are quoted as a fixed scope against a written specification. Where requirements are still open, we quote the discovery phase alone and price the build once there is something real to price.
Discuss a build- Discovery
- Content inventory, conversion path mapping, performance baseline
- Team assigned
- Front-end developer, designer, analytics engineer
- Stack
- Semantic HTML5, CSS, vanilla JavaScript; headless CMS on request
- Testing
- Real-device performance runs, keyboard and screen reader passes
- Hosting
- Your provider or ours, static-first deployment with CDN
- Handover
- Repository, architecture note, recorded walkthrough, 30 days support
Questions we are asked first
Before you send a brief.
If your question is not here, write to info@bari-buti.com and you will get a direct answer from the developer who would build it.
Both are reasonable tools used in the wrong places constantly. A framework adds load time and a maintenance burden that a marketing site does not need, and a plugin-driven CMS accumulates weight nobody owns until the site is slow and nobody can say why. We choose per project and explain the trade-off. If your case genuinely calls for React, you will get React.
Yes. We map which content genuinely changes during discovery and connect exactly that to a headless CMS, leaving layout and performance-critical parts fixed. Editors get a clean interface for their actual job rather than a page builder capable of breaking the site.
Either. If you have brand guidelines we build to them and flag anything that will fail contrast requirements or read poorly at small sizes. If you do not, design is part of the engagement and we produce a layout system rather than a set of static mockups.
Yes. A landing page rebuild can be scoped as a standalone two-to-three-week project, subject to discovery and content readiness. It gives both sides a low-risk way to assess the working process.
Nothing you have to buy. A static-first site with no framework needs limited maintenance. Optional retainers can cover ongoing testing, new pages and performance monitoring, while the repository remains available for your own team or another supplier.
Works well with
The disciplines that compound this one.
A fast site with no traffic earns nothing, and traffic arriving at a slow site earns less than it cost. These three complete the loop.
Next step
Send us the current site, and we will tell you what it is costing you.
The build estimate includes a performance and accessibility assessment of what you have now, with the conversion impact quantified where the data allows.