Selected work

Real problems. Engineered solutions.

We approach every project the same way: understand the actual workflow, identify the real bottlenecks, and build the smallest system that makes the work possible.

FAQ

Questions about our work

What is Sparkline Labs trying to show through its case studies?

Our case studies are intended to show more than the finished interface. They explain the business problem, the assumptions we challenged, the system we chose to build, the constraints we had to engineer around and what happened when the solution entered production.

That distinction matters because a screenshot cannot tell you whether software changed the underlying workflow. A system can look polished while leaving the original business problem untouched.

Our Propertyzone case study, for example, focuses on the distinction between an enquiry and a lead, the role of WhatsApp, structured property data, lead routing and unreliable connectivity because those were the actual engineering problems behind the product.

Are the projects on the Work page client projects or products Sparkline Labs built itself?

Both are possible. The Work page includes case studies from custom builds as well as products that Sparkline Labs has built and operates itself.

Propertyzone is our clearest current example of the second category: it is a Sparkline Labs product that was built around a real market problem and taken into production.

For client work, the same principle applies. We focus on what problem the system was designed to solve and why particular technical decisions were made, rather than presenting a generic list of technologies used.

Why does the Propertyzone case study focus so much on the workflow instead of just the technology?

Because the software was designed around a workflow problem rather than a technology problem.

The property market already had websites, listings, agents and WhatsApp. The harder problem was what happened after someone enquired: whether that enquiry carried meaningful intent, who was responsible for it, whether it could be matched to other properties, whether the agent could respond quickly and what happened to the information afterwards.

That is why the case study examines the system surrounding the interface. The full Propertyzone case study explains how structured data, intent, matching, WhatsApp and agent workflows became parts of the same system.

Why does Sparkline Labs publish the problems and trade-offs behind its projects?

Because the difficult part of engineering is rarely the existence of a feature. The difficult part is deciding what the feature should actually do, what assumptions it depends on and what happens when the real operating environment does not behave as expected.

We therefore document decisions around workflow, data, connectivity, communication channels, adoption and technical risk. Those decisions are useful to potential clients because they show how we think before and during implementation.

They also feed directly into the wider Solutions Engineering body of work we publish from projects we have actually built.