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.
- Industry
- Product platform
- Our role
- Data model, backend, UX/UI, delivery
- Team
- Three — lead + two developers
- Duration
- Multi-phase, ongoing
- Status
- Live, operated by the client
- Hard part
- Unattended work that reports honestly
Recurring work is easy to script once and hard to run for a year
A script that automates a task is a weekend. A system that runs hundreds of those tasks unattended, survives a third party going down mid-run, and can be explained to an auditor eighteen months later is a different piece of engineering entirely.
The brief was a platform non-engineers could operate: schedule work, see what ran, understand what failed and why, and retry it without asking a developer. That requirement drove the data model before it drove a single screen.
Four decisions that shaped it.
Schema before screens
Jobs, runs, attempts and results were modelled as first-class records. Every later feature — reporting, retries, permissions — was a query against that, not a new table.
Queue-backed execution
Work is dispatched to idempotent workers, so a retry cannot double-charge, double-send or double-write. Failures land in a dead-letter queue with their input intact.
Reporting that admits failure
The dashboard leads with what did not work. Silent success is the default state and needs no attention; the exceptions are what the interface is for.
An operator's interface
Designed against real run volumes, not seed data: dense tables, keyboard-first filtering, and a retry that is one click from the row that failed.
How it is put together.
- DATA
- Relational and normalised; migrations in version control, no schema drift between environments.
- API
- One versioned contract used by the interface and by clients — no private back door for the UI.
- BACKGROUND WORK
- Queue with retry policy, backoff and dead-letter capture per job type.
- INTEGRATIONS
- Each third party behind its own adapter, so an upstream change is a one-file change.
- INTERFACE
- Server-driven, mobile-first, accessible; measured on a mid-range phone.
- OBSERVABILITY
- Structured logs and an audit trail per run, queryable by the operator, not just by us.
Stack & disciplines
- Data model
- Backend architecture
- Queues & automation
- UX/UI
- Front-end
Operated by the client, not by us
- Day-to-day scheduling and retries are handled by non-technical staff without developer involvement.
- Third-party outages degrade a single integration instead of stopping the platform.
- Every run is reconstructable after the fact, with its inputs, attempts and result.
- New job types ship as configuration and one adapter, not as a new subsystem.
Volume and uptime figures for this build are the client's to share; available on request.
Other builds.
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 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.