We were already paying for third-party time tracking software. It worked, but it never fully fit the way we worked. Some hours could end up without a useful project attribution, incomplete entries made reporting harder to trust, and there was only so much we could change about a product we did not control.
Then the provider increased its pricing. We couldn’t justify the increase for our use case.
Instead of folding, we asked what we would actually need if we built the tool around our own workflow.
Before writing code, we reduced that answer to a roughly 1,500-word specification. It defined what Cyclops had to solve, what could stay out of the first version, and when those deferred features might become worth building.
Only three days later, Cyclops was running in production. One developer took it from specification to launch, and over the following five weeks we shipped 14 releases.
Once we stopped treating a general-purpose product as the benchmark and focused on our needs, there was less software to build.
The software worked, but we were still adapting ourselves to it
Our existing time tracker did the basic job, but parts of the workflow never fit us particularly well. Hours could be logged without a project and end up in an “Untagged” bucket, which meant we knew time had been spent without knowing what it belonged to.
Incomplete entries created a similar problem. The reports still existed, but once people postponed, reconstructed or skipped entries, the data behind them became harder to trust.
Because the software was built for many different companies, there was a limit to how far we could adapt it to our own workflow. We could work around those constraints, but we could not remove them.
Any tool we built for ourselves therefore had to solve two things from the start. Every hour needed to belong to a project, and logging time had to be easy enough that people would actually keep doing it.
The price increase gave us a reason to question the status quo
The limitations were already there, but they were easy enough to live with while the existing setup still made sense.
Then the provider increased its pricing. The problem was not simply that the software cost more. We were being asked to pay more for a product we still could not shape around our workflow.
That gave us a reason to compare the two options properly. We could keep paying for a mature product with features we did not need and constraints we could not remove, or find out how much software our own workflow actually required.
We were not interested in rebuilding a general-purpose time tracker. We only needed the part that solved our problem. That question became the starting point for Cyclops.
We defined the smallest tool that would solve the problem
Once building became a real option, the next question was how little we actually needed to build.
Before any code was written, Robert turned that into a roughly 1,500-word specification. It defined what Cyclops had to solve, what the first version would leave out, and which questions still needed an explicit decision. Open questions were flagged instead of being settled by accident during development.
The specification also kept a deferred list. A feature could stay out without being rejected forever, but it needed a reason for staying out and a condition for coming back.
Billable rates stayed out because they did not help answer where our hours were going. They would only become relevant if client billing or margin tracking became part of the goal. Timesheet approvals stayed out because they were a heavy solution to data completeness. Weekly totals could solve most of that problem without adding another approval workflow.
By the time development started, Cyclops had a narrow job and fewer open decisions. Anything outside that boundary would have to earn its way in through real use.
Four decisions made a much smaller product possible
Cyclops only needed to fit one workflow, so we could remove choices and states that a general-purpose time tracker has to support.
No project, no timer. The start button stays disabled until a project is selected. An unattributed entry cannot be created because every hour has somewhere to belong before tracking starts.
Choose the project, not the client. Each project already belongs to one client, so selecting the project gives us both pieces of information. That removes one field from the logging flow without losing client-level reporting.
A running timer is just an unfinished entry. It uses the same data structure as a manual entry, with no end time until the timer stops. There is no separate timer workflow or special data model to maintain.
Google sign-in is the access model. There are no separate passwords, invitation flows or seat management. Team members use the account they already have.
We applied the same principle to historical data. People, projects and other records are deactivated rather than deleted, so old reports stay intact even when the current team or project list changes.
Each decision removed a field, invalid state, special case or workflow while keeping the data we actually needed. That is what made a much smaller product possible.
Three days later, Cyclops was running in production
Development started on 30 July with the project skeleton and data model. Wherever possible, rules from the specification were enforced in the database rather than left to the interface, so future changes could not bypass the logic Cyclops depended on.
Over the next two days, one developer built the core API and interface for sign-in, permissions, time entry, reporting and administration. Working from an agreed scope removed the need to revisit product decisions during implementation.
Cyclops was built with AI assistance, but AI was used inside a product boundary that had already been defined. We do not have the same project built without AI, so we cannot say how much time it saved. What we can say is that it helped execute a narrow plan rather than decide what the product should become.
By 2 August, tests and automated checks were in place, the infrastructure had been provisioned as code, and Cyclops was running on Google Cloud. Every change still went through a branch, pull request and code review before merge. Deployment was automated, with a post-deploy health check and rollback if something failed.
Three days did not mean a prototype on someone’s laptop. It meant a production tool the team could start using.
Fourteen releases later, the original bet still held
The narrow first version could have fallen apart once Cyclops met real use. Five weeks and 14 releases later, most changes were still refinements to the same core workflow rather than attempts to turn it into a broader product.
Weekly totals are the clearest example. The specification had deliberately left out timesheet approvals, and actual use confirmed that a lighter solution was enough. Day and week totals gave people the visibility they needed without adding another workflow.
Other releases removed friction around project selection, resuming entries, date picking and running timers, while accessibility and security improvements continued in parallel. The product became easier to use without changing what it was for.
A few deferred capabilities did earn their way in. Task autocomplete was added on 7 September once free-form naming became a real problem, while personal API tokens followed when scripting and integrations became useful. Those additions changed the boundary for a reason, not because we had tried to predict every future need before launch.
After 14 releases, the original scope had changed at the edges, but the core bet still held.
Owning the workflow changed the value of the software
The biggest difference was not simply that we could fix things faster. It was that we controlled the workflow.
Cyclops includes a feedback link inside the app, so friction can be reported where it happens. We can then decide whether the problem is worth solving and whether the product boundary should move. A meaningful share of the first 14 releases came from feedback like this.
Because we own the product, an important workflow no longer depends on another company’s roadmap. If something gets in the way often enough, we can change the software instead of building another workaround around it.
That control only matters when the workflow is specific enough to justify it. Cyclops made sense because the problem was narrow and owning the behavior of the tool had ongoing value. In many other cases, buying existing software would still be the better choice.
When the software no longer fits, question the default
Cyclops did not start because we wanted to build another internal tool. It started because software we were already paying for no longer fit the workflow well enough to make renewing the obvious choice.
The answer was not to rebuild everything the existing product could do. It was to define the part we actually needed, leave the rest out, and let real use decide what deserved to come back.
That is the approach we would take again. Start with the workflow, understand where the current software is getting in the way, then decide whether the better answer is to keep buying, automate around it, or build something narrower.
If your team is paying for software it still has to work around, we can help figure out which of those options makes the most sense. Reach out to us and let's find a solution together.