Web development
Most sites are fast and accessible for about a month. Then a tag manager arrives, a hero video is added, a plugin is installed to solve something a line of CSS would have handled, and by the following spring the site is three times its original weight and nobody can point to the day it happened.
We build sites and web applications where speed and accessibility are properties of how the thing is built rather than findings in a report. That is cheaper, and it survives contact with the next year of changes.
What “built properly” means here
Accessibility
WCAG 2.2 AA and IS 5568, while the code is written.
Performance
A weight and timing budget set at the start, and held.
Three languages
RTL as a layout direction, not a mirrored afterthought.
Motion
Movement that can be turned off, with a visible control.
Accessibility by construction
We build to WCAG 2.2 AA and, for Israeli clients, IS 5568, which is a legal requirement rather than a preference. Crucially we do it while writing the code, not as a remediation pass afterwards.
The distinction is practical rather than philosophical. Retrofitting accessibility means rewriting markup, revisiting every colour decision and rebuilding components that were designed around a mouse. Doing it as you go costs almost nothing: correct elements, a real heading outline, visible focus, keyboard paths that work, contrast checked when the palette is chosen rather than after it is signed off.
This site is the reference implementation. Its colour tokens carry the measured contrast ratios in comments next to them, because a token that was chosen for a reason should say what the reason was.
Performance as a budget, not an afterthought
We set a weight and timing budget at the start and hold to it. Fonts subset and preloaded, images in modern formats at the size they are actually displayed, no render blocking scripts, and third party code treated as the expensive import it is.
The usual reason a site is slow is not the framework. It is images and other people’s JavaScript.
Multilingual that is not a plugin problem
Three language trees, correct lang and dir on every page, RTL handled as a first class layout direction rather than a mirrored afterthought, and hreflang that names each page’s real translations. Hebrew is not a stylesheet variant. Text direction affects layout, iconography, punctuation and how a screen reader announces a Latin brand name inside a Hebrew sentence.
We have built this three times in three languages on this site alone, and every subtle bug we hit is now a test.
Motion that respects the visitor
Animation is fine. Animation that cannot be turned off is not. Everything ambient honours prefers-reduced-motion, and where a site has significant motion we add a visible control as well, because the operating system setting is not something every visitor knows exists.
What we build with
WordPress when the client needs to edit content and the site is content shaped, built as a bespoke theme rather than a page builder on top of a template. Page builders trade a fast start for permanent weight and a structure nobody can change later without the builder.
Laravel, Next.js or React when the thing is really an application that happens to have pages. The deciding question is whether the hard part is publishing or behaviour, and the answer picks the stack rather than the other way round.
Either way the markup is ours, the CSS is ours, and you are not paying a performance tax for a framework’s assumptions about a site that is not yours.
What we will tell you not to do
If all you need is five pages that never change, a good template on a hosted platform will cost you a fraction and we will say so. That is a different thing from a small job: a campaign site that has to be live on Thursday is work we do constantly and do quickly.
Where we are worth the money is when the site has to be fast under real conditions, has to meet an accessibility standard you can be held to, has to work in more than one language properly, or has to talk to systems behind it.
How the work runs
Discovery covers what the site has to do, who has to be able to use it, what the content model actually is, and which systems it has to connect to. Then design and build run together rather than in sequence, because a design handed over as pictures always contains decisions that cannot survive being built.
We check accessibility and performance continuously during the build, not at the end. A contrast failure found while choosing the palette is a five minute conversation. The same failure found at launch is a redesign.
Related
Where a site is really an application, see custom software platforms. Where it is a store, see e-commerce engineering. Where it has to talk to systems behind it, see system integration.
Common questions
How long does a site take?
A content site with a real design and a proper content model is usually six to twelve weeks. Multiple languages add time to content and translation rather than to engineering, since the structure carries all three from the start.
Will our team be able to edit it?
Yes, and that is a design constraint rather than an afterthought. We build editing interfaces around the content that actually changes, so there is no way to accidentally break the layout by editing a paragraph.
Is accessibility really a legal requirement?
In Israel, for most businesses, yes. IS 5568 references WCAG and the obligation is real. Beyond compliance, the same work makes a site usable on a bad phone on a bad connection, which is a much larger group of people than most site owners assume.
Can you fix our existing site instead of rebuilding it?
Often yes, and it is usually the better value. Performance and accessibility work on an existing site delivers most of the benefit for a fraction of a rebuild. We will tell you when a site is genuinely past repair, and the honest answer is that most are not.
Do you do the design as well?
Yes. See UX and UI design. We are equally happy building from a design another studio produced, and we will raise the parts of it that will not survive being built before we start rather than after.
More services
Next
Tell us what you are building, or what is breaking.