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.