Why We Created Lighthouse and What We Learned So Far
A reflection one year after the first commit
On February 10th, 2025, Lighthouse turns one year old. On the same day in 2024, the first commit to the GitHub repository was made (back then, it was still called CMFT—Continuous Monitoring and Forecasting Tool). In this post, I’d like to share what led to the decision to create it in the first place, why I’m spending hours of my free time building it, and what we have learned so far.
Lighthouse is the flagship product of Let People Work. It allows you to forecast completion dates with confidence and supports a wide range of scenarios, including projects with multiple teams and handling features that are not broken down yet.
It’s free to use, is open-source, and doesn’t need any cloud connection.
Join our Slack Community to learn from other users and become part of the development.
Consultants and American Football - How It All Started
Yes, you’ve read that right. Two main reasons why Lighthouse was created were the statements of an external consultant on one hand and American Football on the other.
In January 2024 we were working with a consultancy that was engaged to help us deliver a new product. During a discussion about Quality, Practices, and Continuous Integration, a lead developer said:
It doesn’t make sense to have green pipelines. We’re in the development phase, so the tests can’t always be working. This is also why we should use Gitflow to keep the main branch stable.
I was puzzled at such a statement, especially for a greenfield project using state-of-the-art technology. My inner developer was shocked and angry: That’s not how we are supposed to do things in 2024. However, after some time, I was wondering whether I might just be out of touch. I have not been writing much code in recent years (apart from a few scripts), so who am I to think I know better. Don’t get me wrong, I was still convinced that the statement was not correct, but I wanted to gain some practical experience again instead of just assuming things.
A Highly Competitive Idiot
Before I elaborate on what the National Football League has to do with the creation of Lighthouse, a quick note on myself. I’d describe myself as a highly competitive idiot. Everyone who will work with me for some time will know what I mean (and that I mean this most positively) with the idiot part. I like to have fun and not take things too seriously (frantically points at all the memes).
If you wonder how it is to work with a highly competitive idiot, reach out to us at Let People Work and we’ll find a way so you can experience this
What many might not see behind the memes is that I’m ultra-competitive. If you tell me that I can’t do something, you can be sure I will invest a lot of time to prove you wrong (yes, it’s that easy to get me to do something). I don’t see the point of aiming for mediocracy (“Well it’s not great, but the others are not better either”). I do understand we can’t be the best in everything, but it’s no excuse for just accepting mediocre or subpar practices.
The great thing about working in the Software industry is that the bar keeps moving, what was state of the art 5 years ago, might be seen as outdated today. This also means that once we get to state-of-the-art, and we keep improving, we get to define state-of-the-art.
Now if someone comes and sells me something outdated 10 years ago (hello Gitflow…) as the thing we should certainly be doing, I get triggered…
American Football
If you are following the NFL, you are probably aware that in the first weeks of February, the Super Bowl is happening. This ends the season, and it will take till September until the new one begins. The Super Bowl in 2024 happened on the 11th of February, just after I had the conversation described above.
This is important because this meant that suddenly my Sunday evenings were free (in Europe, most NFL games happen on Sunday evenings). Instead of watching games, I have time to spend on writing code. And I could do this in the way I wanted to.
Do Things My Way
The cool thing about personal projects is that you can do whatever you want, however you want. My goal was, apart from the actual product that was built, to make sure I could refresh my knowledge of various engineering practices, and (re-) gain practical experience. Specifically, I wanted to do:
Use Test Driven Development as good as I could
Do Continuous Integration and Continuous Deployment
Some proof for that is visible below, as the first commits show that one of the first things I did was to add CI Pipelines, integrate with SonarCloud to check the code, and add tests:
I tried to use those practices wherever they made sense. And the more the project grew, the happier I was that I invested in proper engineering practices. While going into detail on all the practices and how they helped me develop deserves its own blog post, the conclusion I can draw after one year is that it’s certainly not impossible to keep the pipeline green.
Make Forecasting Accessible
Next to my personal reasons for starting this project (remember, I basically just wanted to prove that certain engineering practices work), another driver was to make the topic of forecasting a bit more accessible. In the weeks before, I did a post on How Monte Carlo Simulations work, which got some attention. I wrote a basic tool in Python to run simulations based on CSV data, but thought that there could be something more accessible and feature rich.
A 15% Forecasting Solution
While there were various tools, from spreadsheets to full-fledged Cloud services that integrated into Jira and Azure DevOps, I had the feeling that something was missing. You either get very basic functionality, or you have to pay quite some money for and/or need some high-level access to your systems (to install new plugins in Jira/Azure DevOps).
At Let People Work, we discussed this and concluded that there is a gap for a forecasting tool that would allow someone in a big corporation to try out this way of forecasting. It should be a 15% solution, something that can be tried out without the need to ask for money or permission from anyone. For this, the tool would need to be:
Free to use
Open-Source (in case internal IT catches wind of an unauthorized tool they can go and check the code if they want)
Run locally (no need to upload to some cloud service that you may not trust)
While we aim to build up services around the tool, what we develop shall remain available for the people we had in mind initially.
What Have We Learned
To wrap up this post, I want to share some of the learnings that we had within the first year of Lighthouse's existence.
Technology and Practices
I am a Software Engineer by trait, but in my professional developer life, I mainly worked on Desktop Applications (.Net/C#/WPF) before in 2019 I switched towards a full-time Scrum Master role. So Lighthouse was a chance to catch up on all the fancy tech and practices. The following things were new to me (meaning while I knew those things, I haven’t built something proper beyond a “Hello-World” with them) and I learned over the last year while building Lighthouse:
ChatGPT (to write code)
The engineering practices (TDD, CI/CD) were crucial, as several major refactorings happened within the first year. Having an extensive test suite made this possible without breaking (too many) things in the process.
Product Management
Apart from the technology side of things, we also started to learn things about product management. As people started to use it, we got feedback and feature requests. As the tool is free to use, we’re spending our free time on it. So as time goes on, we learn about how to best manage stakeholders, we experiment with how we can scale up (maybe having 5 different communication channels isn’t the smartest idea…), and what features to really follow up on and what to drop (saying no to things is a lot easier if you work on it on the weekends).
Conclusion
Lighthouse started as a hobby project for me, trying to catch up with technology and engineering practices. This is something I would recommend to everyone, instead of just claiming some random stuff about how AI will change the industry on LinkedIn, go actually build something and learn while doing it.
And as we head into Super Bowl LIX (go Eagles!), this also means our time will free up again. So try out Lighthouse, join our Slack Channel, and help us make your forecasting experience better!