What we test for
Typical work
- Design systems built once and used by every team
- Interfaces that survive a long translation, a small screen and a zoomed browser
- Accessibility work that passes an audit rather than a plugin
- Replacing the pile of overrides a UI collects over three years
The coding test
Build a component from a design: responsive, themeable, operable by keyboard and correct in a screen reader. Then we hand you the same component with four years of overrides on top and ask you to make it match, without breaking the six pages already using it.
Five interview questions you can reuse
We use questions like these in our soft-skills and technical rounds. Steal them for your own interviews.
How do you stop a stylesheet becoming a pile of overrides?
A strong answer covers: Tokens and a scale instead of magic numbers, styles scoped to the component rather than to the page, and no selector that wins by being more specific. If the fix for a layout is !important, the layout is wrong.
What breaks a layout that looked fine in the design?
A strong answer covers: Real content: a long word in German, a missing image, three lines where the mock had one, a 320px screen, and a user zoomed to 200%. Design for the extremes, because that is what ships.
What does accessible actually mean when you build a component?
A strong answer covers: Operable by keyboard in a sensible order, announced correctly, visible focus, state never carried by colour alone, and enough contrast. An automated checker catches perhaps a third of that; the rest is someone testing it.
When do you reach for grid, and when for flexbox?
A strong answer covers: Grid when the layout is two-dimensional and the container decides; flexbox when the content decides along one axis. Most real layouts are grid outside and flex inside, and six nested flex containers is the sign you wanted grid.
How do you theme a product without duplicating the stylesheet?
A strong answer covers: Custom properties for the tokens, redefined per theme on one ancestor, with components reading tokens and never raw values. Dark mode is then a token swap instead of a second set of rules.
One monthly price per developer. Everything in it.
No deposit, no minimum term, no placement fee. You pay one invoice a month for each developer on your team.
Per developer, all-in. Your quote arrives by email with your exact number after you send the brief.
- Developer pay, local payroll and taxes
- Vetting: coding test, soft skills, English
- Free replacement within 90 days
- A direct line to our CEO
What changes the price
- Seniority and role. Senior engineer, tech lead or architect.
- Stack. Some stacks and niche tools cost more to staff.
- Team size. Larger teams get a better monthly rate per seat.
- White-label. Agencies reselling under their brand get partner pricing.
Terms in plain words
- First 2 weeks risk-free: if it isn't working, you don't pay for them
- Month to month, 30 days' notice to end
- No deposit and no minimum number of seats
- Want to hire the developer full-time? Buyout of 3 months' fee in year one, 2 months' after
Questions tech leads ask us
How senior are your CSS engineers?
Six or more years in front end, with a design system they built or maintained. We ask what they did about the component everybody was overriding.
Is this a designer or an engineer?
An engineer. They work from your design and your tokens. They do not replace a designer; they make the design real and keep it that way across every screen and browser.
Can I see the coding test results?
Yes. Every profile card carries the score and the reviewer notes.
What does it cost?
$6,900 per developer per month, all-in, and flat: the same rate whatever the stack. Your exact quote arrives by email after you send the brief.
Skip the sales rep. Talk to the CEO.
Tell us what you're building, your stack and when you need people. Three matched profiles within 48 hours, and a straight answer on whether we're the right fit.