In 2025, 37signals permanently deleted their AWS account.
If you’re not familiar with 37signals, they are the people behind the project management app Basecamp. This was no accident, but rather the conclusion of nearly a three-year journey of moving away from a public to a private cloud infrastructure.
Why did 37 signals decide to undertake such a drastic step? The simple answer is cost. According to David Heinemeier Hansson, co-owner and CTO of 37signals, their annual S3 bill alone was $1.5 million (source) and in 2022 the company’s total cloud costs exceeded $3.2 million. https://www.linkedin.com/feed/update/urn:li:activity:7386172918193586176
After the migration and the initial investment in their own server infrastructure, 37signals projects their cloud computing costs to be approximately $200,000 per year. The company estimates that this move will save them over $7 million over five years (source).
For decades, we’ve been conditioned to believe certain “truths”. One of the most prevailing beliefs is that the public cloud is the only viable way of building your infrastructure.
The only way is the cloud. It’s not. At least, not always. Another belief is that when it comes to software, buying is better than building. That’s also not always the case. To illustrate this, I want to share the story of how I built an internal tool for my former agency.
Why does Hypertime exist?
Hypertime is a no-frills, simple, and intuitive time tracking web application. It was built as an internal tool for OM Group (formerly Ogilvy Group). Hypertime was meant to replace the clunky Excel spreadsheets that had previously been used to collect and analyze timesheet data. Before taking the plunge, I tested dozens of time tracking solutions from Clockify, Toggl, Harvest to Hubstaff and many others. All these platforms had great features, top-notch functionality and excellent user interface.
However, none of these platforms meaningfully addressed the unique needs, workflows, taxonomy rules, and other requirements from the companies that are part of OM Group. After all, how do you find a tool that is equally useful and easy to use for a copywriter in a creative agency as it is for an account executive in a media agency? You don’t. You simply have to build it.
Here is everything I learned during the process of managing the development of Hypertime.
1. Identify which problems are worth solving
One of the biggest mistakes in software development is feature bloat. It’s such an easy trap because we all face multiple challenges and we want to find solutions for all of them.
Feature bloat can slow down the development process and drain your resources.
In the case of Hypertime, the platform had to solve the following core issues:
- Using an Excel template for timesheets was slow and tedious.
- Collecting and consolidating timesheet data from hundreds of Excel files required hours of manual labor and clerical errors were very common.
- Analyzing timesheets required manually transforming the data into a usable format.
- Existing timesheet web applications had unnecessary features that we did not need, yet could not be configured to meet our taxonomy requirements and lacked user management controls that matched our corporate structure.
My starting point was creating a list of features that addressed these specific problems. These features would be the foundation of the MVP and any other ideas or improvements would be added as the project evolved. In most cases the best approach is to identify the core features of your product and launch it as soon as possible to gather user feedback. A great example of building upon the MVP is Hypertime’s room scheduling interface. Around the time Hypertime was released, my former agency had to move to a new office. We moved to a bigger space along with another agency part of OM Group. Although a room booking feature was not in the original scope, I quickly realized that we needed to find a way to manage the four conference rooms in the office. So, we switched gears and built a simple room management system within Hypertime. https://youtu.be/Rap2aCiYnNo
2. Understand how users behave and reduce friction wherever possible
Some employees prefer to complete their timesheets on a daily basis, while others (like me) procrastinate till the very end of the month. Then, on the last day they input all their hours in one session. For the first set of users we created a daily tracker. You simply select a day and then add all the projects you worked on. For the second set of users we implemented an Excel-like interface for the entire month. Our insight was that users would feel more comfortable working with an interface that felt like Excel. However, our important realization was that regardless of how users prefer to do their monthly timesheets the data ends up in the same place – an SQL database. So, we made two different workflows depending on what users feel most comfortable with at any given time.
https://youtu.be/o6UIMv-iYWg
3. Comparison is the thief of joy
Researching other platforms is a great way to find inspiration or to discover a solution to a problem in your own application. However, a common side effect of doing too much research is measuring your progress against companies backed by tens or even hundreds of millions of dollars in investment. Personally, I like Notion. I like their approach to UI & UX design. I am always impressed by how quickly and how often they launch new features. However, every once in a while I have to remind myself that Notion raised over $343 million to get to this point. While researching other SaaS tools you will inevitably find great examples of UI features. Some of these will seem clever and simple, but in fact would require hours of coding and testing. Sometimes the simplest things are the hardest to implement.
4. Always assume that users will make mistakes when using your app
I made the conscious decision to implement ways to undo certain changes and retroactively edit some user inputs. For example, if a user submits a timesheet but realizes there is a mistake, an admin can reject the timesheet and allow the employee to submit it again.
https://youtu.be/DpZvq7eQ_3A
Another place where I deployed a fail-safe mechanism was the salary flights interface. The idea behind salary flights is to have highly granular cost data and allow for dynamic cost modeling. What this feature does is allow a company director to input an employee’s hourly rates for multiple and different date ranges.
Let’s say an employee started working for you in January at an hourly rate of $50. On March 12th you promoted them and bumped their hourly rate to $55. https://youtu.be/dGntn2YsFu8
However, a few months later you realize that you accidentally set the wrong date for when the pay rise went into effect.
Not to worry! You simply have to go into the interface and correct the date or the hourly rate. Once you’ve done that, all cost data will be recalculated and all dashboards will be updated.
5. Writing technical documentation sucks and you will hate it
Outlining the scope of the project, drawing user flow diagrams, and writing user stories are all integral parts of creating a successful project. However, for most non-technical people it will be a major and persistent challenge, not to mention a very humbling experience.
Chances are that you will have to go over your documentation multiple times and update it as the project moves forward. My recommendation is to use a platform like Miro. It’s quite versatile and gives you a place to brainstorm with your team, draw user flow diagrams, and much more.
If you don’t have experience with Figma, you can create quick low fidelity prototypes in Balsamiq. You can always outsource these tasks to a dedicated project manager or an outside agency, but sitting down and writing the feature list, the user stories and other types of documentation will help you coordinate the project more effectively. Speaking of outsourcing, getting a great UI/UX designer will save you a lot of headaches.
6. Ask for feedback the right way and from the right people
When it comes to feedback, quality is always more important than quantity. The worst type of feedback is from people who impulsively and reactively criticize something without making the effort to understand it. Avoid feedback from such people at all costs. It’s also important how you ask for feedback. Make it easy for users to share their opinion. In your surveys or user interviews, ask simple and direct questions that allow respondents to share both positive and negative feedback. In one survey, I asked whether Hypertime was easier than using Excel spreadsheets. The result was overwhelmingly positive with 85,7% of respondents saying they preferred Hypertime. This signaled that I was on the right track. However, I also made sure to include questions that would elicit critical feedback as well. This is how I learned that users were annoyed that they couldn’t see a more detailed summary of their timesheet. Another great insight was that the app did not make it clear enough that users could create and reuse a timesheet template. We addressed these points and more in subsequent Hypertime updates.
7. Maintenance is mandatory
One of the disadvantages of building internal software is maintenance. You will need to monitor for bugs and crashes, keep your technology stack up to date, and ensure security compliance.
Furthermore, you will need a roadmap for future development. Adding new features and quality-of-life improvements will ensure the longevity of your software.
For example, before handing over Hypertime, I made sure that we had updated to the latest versions of PHP and Laravel. This was especially important for security reasons and ensured the team wouldn’t have to make any major changes to the software for at least two years.
None of this is simple or easy and requires a competent team and a good project leader. Final thoughts This is by no means an exhaustive list. In fact, I can think of a dozen more lessons that I learned while building Hypertime.
However, the main takeaway from this article is that building internal tools is a viable alternative to buying SaaS subscriptions. You just need to know what problems you are trying to solve, set realistic goals, and assemble the right team for the job.
Anyway, thank you for reading, and good luck!
P.S. Special thanks to Alike for creating the videos for this article.