Sumlo is a SaaS product Simplepage built in one long weekend - Friday-evening scoping to Monday soft launch - that turns Toggl, Harvest and Clockify timesheet exports into branded PDF reports a client can actually read. It shipped in three days because the hard part, the PDF engine, already existed, and because we knew six retainer clients with the exact problem it solves. The first paying user arrived the day of the soft launch. This is the honest account of how the weekend went, including the iceberg of prior work underneath it.
Why did we build Sumlo?
The origin story is a 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.
How do you scope a product to fit a weekend?
The trick is a brief that a small team can finish in the window they have allowed - rapid development does not start with code. 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.
What did we build on Saturday?
The skeleton is a .NET 10 application with 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.
How did Sunday go?
The Sunday list is short: branding in the morning, payments in the afternoon, polish in the evening.
The branding layer took about four hours. Upload a logo, pick two brand colours, see a live preview, save. The branding data lives on the account, so it is applied to every report the user generates without them having to think about it.
Payments went through 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.
How did the launch go?
The result is easy to summarise: one paying customer on day one. 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 did we learn from building Sumlo in three days?
The lessons are four, and none of them are about typing speed.
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.
Should you build your product this way?
Yes, if the idea 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.