Mituteed.
A public-facing Estonian platform built on a schema designed to stay legible as the product grows, with the interface drawn against the real data rather than a mockup.
- Industry
- Web platform
- Country
- Estonia
- Our role
- Backend architecture, UX/UI, front-end delivery
- Team
- Three — lead + two developers
- Duration
- Design to launch
- Status
- Live
- Hard part
- Staying fast while the catalogue keeps growing
A public product that has to stay fast while it keeps growing
Public platforms accumulate content and traffic in the same period they accumulate features. Get the model wrong and the third content type is the one that starts the rewrite.
We designed for the version of the product two years out: content modelled generically enough to extend, specific enough to query cheaply, and pages that stay fast on a mid-range phone over mobile data.
Four decisions that shaped it.
One content model, several shapes
A single well-shaped model serves the list, the detail page and the search index, so adding a category does not mean adding a subsystem.
Interface drawn on real records
Layouts were built against production-shaped data from the first week — including the long names and the empty states.
Mobile-first delivery
The phone layout was designed first and measured on a mid-range device; the desktop view is the same page with more room.
Editing that non-developers own
Content, copy and structure are maintained by the client's own team without touching code or waiting on a deploy.
How it is put together.
- DATA
- Relational schema with the growth path designed in; indexes chosen from the real query set.
- API
- One read path shared by pages and search, cached where the data allows it.
- INTERFACE
- Mobile-first, accessible markup, no client-side framework where the page does not need one.
- INTEGRATIONS
- Third-party services isolated so a slow response never blocks a page render.
- CONTENT
- Client-editable structure and copy, versioned, with no deploy in the loop.
- DELIVERY
- Measured on a mid-range phone over mobile data before each release.
Stack & disciplines
- Content architecture
- Backend
- Performance
- UX/UI
- Front-end
Live, and maintained by the client
- The client's team publishes and restructures content without engineering time.
- New content types have shipped without schema rewrites.
- Page performance holds on mid-range phones as the catalogue grows.
- Same three people still available after launch — no maintenance handover.
Traffic and performance figures are the client's to share; available on request.
Other builds.
AutomateOnline
A platform for automating recurring online work: scheduling, background processing, retries and a full audit trail, with an interface an operator can actually run it from.
Hard part: Unattended work that reports honestly
View case study
KibRide
A ride-hailing platform for North Cyprus — passengers, drivers, live tracking, upfront fares and scheduling, all driven by one real-time state model.
Hard part: One state model for three different audiences
View case study
Säästupark
A consumer-facing platform where third-party systems are held at arm's length from the core, so an outage upstream degrades one feature instead of the product.
Hard part: Surviving other people's downtime
View case studyHave a build like this one?
Send the brief and get a candid assessment of the hard parts — including a clear no, with a reason, if it is not right for us.