The problem was on the Friday spreadsheet
Every month, Sharon spent the first Friday afternoon of the month turning a Toggl export into something a client could actually read. Raw CSV in, pivot tables, conditional formatting, branded PDF out. The work itself was fine. The repetition was not. By the end of 2025 we were doing this for six retainer clients. That is six Friday afternoons a year gone to formatting spreadsheets.
If you run an agency, you know the shape of this problem. The hours are billable in theory. In practice they are overhead, and they eat into the Friday afternoon where you would rather be finishing a piece of client work or, frankly, knocking off early.
One Friday in January, over a cup of coffee, we decided the next day we would stop doing it by hand. Three days later there was a working product with paying users. That product is Sumlo. This is how it went.
Friday evening - scoping the weekend
Rapid development does not start with code. It starts with a brief that a small team can finish in the window they have allowed. Our window was the weekend. That forced hard decisions before anything was written.
We agreed what Sumlo would do:
Accept a Toggl CSV export (plus Harvest and Clockify exports, since they all produce similar shapes)
Generate a branded PDF with hours grouped by project and task
Let the user drop in their logo and brand colours
Send the PDF to the client by email, or download it
We agreed what Sumlo would not do:
Live sync with any time-tracking API (CSV in, PDF out - no OAuth, no tokens, no webhooks in v1)
User management beyond one login per account
Custom report layouts (one opinionated template only)
Invoicing, quoting, any kind of CRM
Two hours. Brief written. We had the list of things Sumlo would do and a shorter list of things we were explicitly refusing to add until v1 was paying for itself.
Saturday - the skeleton
.NET 10 application, SQL Server behind it, hosted on the same stack we use for Umbraco sites. Nothing clever. By Saturday lunchtime we had the upload form working and a parser that could read a Toggl CSV into a normalised model. Harvest and Clockify fell out of the same model with per-source adapters, about 90 minutes' work each.
The PDF engine was the next decision. We used Printo, a PDF service we had already been building for internal use. Printo takes a Razor template plus a JSON payload and returns a rendered PDF. Meaning: we wrote the Sumlo report as a Razor view, threw the parsed timesheet data at Printo, and got back a PDF. By dinnertime Saturday the full Upload → Parse → Render → Download flow worked end to end.
There is a lesson here and it is not glamorous. Sumlo shipped in three days because we had already built Printo. Two products ago we spent three weeks building the PDF engine that turned the Sumlo weekend from impossible into routine.
Sunday - branding, payments, polish
Sunday morning was the branding layer. Upload a logo, pick two brand colours, see a live preview, save. About four hours. The branding data lives on the account, so it is applied to every report the user generates without them having to think about it.
Sunday afternoon was payments. LemonSqueezy for the checkout (we use it across all our products because Stripe is not available on the Isle of Man, where Simplepage is registering as a company). Three pricing tiers live at launch: Solo at £9 a month, Team at £29 a month, Agency at £79 a month. A 14-day trial on each.
Sunday evening was polish. We fixed the things that would make a paying user close the tab. The logo preview was laggy, so we cached it. The timesheet parser choked on Toggl's optional columns, so we made the column mapping lenient. The PDF had a 2px misalignment on the header row, so we fixed the row, took a screenshot for the marketing site, and moved on.
Monday - the soft launch
Monday morning we sent sumlo.io to five people we trusted to tell us when something was broken. One of them, a freelance developer who tracks in Clockify, had a report in her inbox within an hour. She paid for the Solo tier the same day.
That is as close to a signal as a weekend-built SaaS product is ever going to get. The next week we wrote the onboarding emails, added the testimonials block, ran the SEO checks, and pushed the public launch.
What we actually learned
Own the building blocks. Printo existed before Sumlo did. If we had to build the PDF engine from scratch, Sumlo takes a month, not a weekend. Most "built in X days" stories have an iceberg of prior infrastructure under them. We think this is honest, and worth saying.
Refuse features. The list of things Sumlo does not do is longer than the list of things it does. Every one of those "does not" items came up during the weekend. "Should we add Xero integration?" No. "Should we support custom PDF templates?" No. "Should we do invoice generation too?" No. If you cannot ship v1 without adding a feature, the v1 scope is wrong. The CTO role of a two-developer team is mostly saying no.
AI-assisted does not mean AI-written. Claude Code wrote about 40% of the lines of code in Sumlo, mostly the boilerplate: model classes, the CSV parser tests, the LemonSqueezy webhook handlers. The architecture, the data model, the Printo template, the pricing decisions, the error handling: all human. This is what we mean when we say AI is a tool, not a crutch.
Three days is not the story. Three retainer clients paying for it is the story. A working product that nobody wants is worse than nothing. The reason the weekend build worked is we already knew six people who had the exact problem Sumlo solves. If you are building a SaaS without a specific buyer in mind, adding speed will not save you.
If this story is relevant to you
If you have an idea that is already solving a real problem, either for you or for customers who keep asking, Simplepage will help you turn it into a working product fast. The service is Rapid Development. The proof is this post, plus Eddi, Patch, and whatever we ship next month.
Or if you just want to turn Toggl timesheets into PDFs without a weekend of your own, Sumlo is live, it has a free trial, and it works.