← Back to the quickler story

Why Philip Ross started quickler.

quickler did not begin as branding in search of a product. It came out of repeated delivery work across charities, publishing, and operations, where the pattern kept recurring: the facts existed, the work was real, and yet the useful output still had to be rebuilt afterwards.

Based in Scotland Background Engineering and automation Delivered before launch 6 workflow systems Company formed March 2026

Founder article

Philip Ross founded quickler in Scotland after years of building practical systems for organisations that had already done the hard part of the job, but were still losing time to the cleanup afterwards. The company is new. The underlying pattern is not.

Before there was a company

He studied Electrical and Mechanical Engineering at the University of Strathclyde, then worked at Dijuno, an AI analytics startup, where he built experience in LLM testing, prompt engineering, and Python automation. The more important thread, though, came through delivery work: building systems that solved awkward repeated work in the real world rather than in theory.

Before quickler became a company, he had already delivered six workflow systems across charities, publishing, and commercial operations. That work covered fundraising automation, production tracking, sales-data restructuring, till-data automation, and document-led approval workflows, with measured time savings across the portfolio.

The recurring problem was simple: the useful context already existed, but somebody still had to reconstruct the finished output by hand.

The turn in 2026

March 2026 was the point where that delivery experience turned into a clearer company direction. Work on the quickler site began on 6 March 2026, the quickler name was settled publicly on 9 March 2026, and Companies House shows quickler Ltd was incorporated on 16 March 2026.

That mattered because it forced a decision. Instead of treating each workflow as a one-off consulting exercise, the better route was to build one company around the pattern itself: repeated operational work that becomes slower, shakier, and more expensive because the structure comes too late.

What he is building now

His work now focuses on two connected areas. The first is workflow systems that turn evidence from the job into better structured outputs without making the process vague, brittle, or hard to trust. The second is AI agents that load the right context before helping with repeated operational work, so the answer is grounded in rules, history, and the actual task rather than guesswork.

A private cycling coach AI is one example of that approach in practice: real data, explicit rules, and rolling memory before any answer is given. The principle is the same in business software. If the context matters, the system has to respect it.

The common thread throughout is straightforward: thoughtful systems, real-world usefulness, and software designed to remove admin without removing structure.