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.
- Industry
- Web platform
- Country
- Estonia
- Our role
- Backend architecture, integrations, UX/UI
- Team
- Three — lead + two developers
- Duration
- Design to launch
- Status
- Live
- Hard part
- Surviving other people's downtime
The product depends on systems it does not control
Anything consumer-facing that pulls data from outside inherits every one of those services' bad days: timeouts, changed fields, silent partial responses.
So the integration boundary became the design problem. Each external service was given its own adapter, its own failure mode and its own cached last-known-good state, and the interface was designed to be honest about what is stale.
Four decisions that shaped it.
Adapters, not direct calls
No page talks to a third party. Each service sits behind an adapter with a timeout, a retry policy and a documented response shape.
Last-known-good state
When an upstream fails, the platform serves the last verified data and says so, instead of showing an error or, worse, a blank.
Honest interface states
Loading, stale and unavailable are designed states with real copy — not spinners standing in for a decision nobody made.
Consumer-grade front end
Fast first render, accessible controls, and layouts that hold up on the phones the audience actually uses.
How it is put together.
- DATA
- Own canonical records; external data stored as cached, timestamped copies.
- API
- Single contract; no external call made in the request path of a page render.
- INTEGRATIONS
- One adapter per service with timeout, retry and schema validation at the boundary.
- BACKGROUND WORK
- Scheduled refreshes with backoff; failures alert instead of silently ageing.
- INTERFACE
- Designed states for loading, stale and unavailable; mobile-first, accessible.
- OBSERVABILITY
- Per-integration health visible to the client, not buried in our logs.
Stack & disciplines
- Integrations
- Backend
- Resilience
- Responsive UI
- UX/UI
Upstream failures stopped being incidents
- An external outage now degrades one feature and shows a clear state instead of breaking pages.
- Integration changes are contained to a single adapter file.
- The client can see the health of each external dependency without asking us.
- Consumer-facing performance held through launch traffic.
Availability and traffic 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
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.
Hard part: Staying fast while the catalogue keeps growing
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.