From engineering leader to solo founder: my journey building Laburo

Taking a leap and building Laburo as a solo founder has been an incredible learning experience!

by João | 12 Jun 2025

Navigating today’s job market can be a brutal experience. I know because I was applying to countless roles and struggling to keep track of them all. That sparked the idea for Laburo as a way to solve my own challenges.

I come from more than a decade working at the same company in various roles, progressing from software developer to engineering manager, culminating in a portfolio and technology engineering leadership position. After five years primarily focused on leadership and strategic initiatives, I wasn’t sure if I could still code effectively on my own. So here I am knowing that my last hands-on software development work was over 5 years ago doing native mobile and full stack development, and I want to build a web platform to start Laburo.

Laburo is your all-in-one job application tracker designed to streamline how to manage and keep track of job applications. It offers powerful time-saving features like automatically extracting and storing key details from a single job advert link, stress relief features like automatically monitoring job adverts and notify you when they disappear, and valuable analytics and insights to help you understand which job application strategies work best.

After validating this idea with friends, ex-colleagues, and people in the job market, I set out knowing only three things:

I wanted to build this platform and release it commercially.
I wanted to use AI to assist me and learn how to better take advantage of it.
I didn’t want to spend any money building and making the prototype and MVP available.

I did spend ~60 USD on the domain and some mailboxes but couldn’t really find free alternatives to those 😅. Everything else was just time investment, including some sleepless nights. My vision was to create a tool that would empower job seekers, from recent graduates to experienced professionals navigating career transitions, streamlining the way we manage the application process.

Sharing my journey early on might seem bold, especially given that Laburo is still in its early stages. However, I believe that even if this project doesn't reach massive scale, the lessons learned can benefit others embarking on similar ventures. Even if this idea doesn’t go far, your’s might.

The foundation: tech stack and initial decisions

By this time I had grown slightly addicted to run local LLMs on my Mac Mini M4 Pro using LM Studio, drawn to a better privacy model, greater control over data and to get a deeper understanding of how these models work. The ability to keep sensitive code and application data entirely offline was particularly appealing to me.

With everyone trying out all the new cool (and sometimes over-hyped) online AI coding assistants and agents, I decided to try out a slightly different approach and understand if local LLMs could be a viable and equally productive alternative. As an engineering leader, I’m always looking for ways to empower teams with innovative tools while maintaining control and security, this felt like a worthwhile experiment.

LM Studio with local LLMs has been a great tool to learn and try out different ideas and solutions around AI but it has its limitations. The obvious one is that it lacks the tools you may find on online LLMs like the ability to use online resources. This means the knowledge you can take advantage of goes only as far as late 2023 or early 2024 which seems to be the cutoff date for most of these models.

Though not knowing about current events it’s irrelevant for what I wanted to use it, not knowing about a latest major version of a given technology you’re using can become a problem. Being aware of these limitations is critical to be able to work around them.

Another key consideration when deciding on the tech stack was to select one that was well supported by the community and by the AI assistant. My goal was to quickly build the prototype for further validation and easily scale from there to MVP. I resisted the temptation to use tech stacks I was comfortable with and just focus on getting the best tools to deliver the intended outcome, even if that meant I had to learn a new stack which I was happy with anyway. My past experience and the fact I was already polyglot in different languages and platforms gave the confidence to move forward.

Eventually I settled on the following stack:

Next.js which provided a fantastic foundation for building a performant web app with server-side rendering and static site generation.
- The Node.js community and ecosystem is quite mature. It’s easy to find resources and components that greatly sped up the development of some features. Server-side rendering was crucial for optimising initial page load times, which is especially important for users on slower connections.
- Typescript added a layer of safety and predictability to my development process and I wouldn't have felt comfortable building this without a strongly-typed language..
- TailwindCSS dramatically sped up UI development. CSS was never my strong suit and TailwindCSS made it incredibly easy for me to develop the UI/UX.
PostgreSQL, through Supabase which already offers Row Level Security (RLS) out-of-the-box. RLS ensures that each user can only access their own data, providing a secure and privacy-respecting environment. One less security concern for me to worry about 🤩.
- Authentication and user management is also done using Supabase which has great Next.js support and integration, aligning easily with Postgres’ RLS.
- The web UI is powerful and easy enough to manage my database. I even track my KPIs through custom SQL queries saved on Supabase’s interface.

What worked:

The combination of Next.js, TypeScript, TailwindCSS, and Supabase proved to be an excellent choice for rapid development building a performant and secure, web application.
Node.js and Typescript are well supported to run serverless functions (lambdas) and to start integrating AI into some more advanced features of Laburo.
The ability to keep code and data offline still getting assistance from AI can be a significant benefit for security-conscious development.
Using local models allowed for rapid experimentation with different models without external dependencies or costs.
With seamless integration with Next.js and Postgre’s RLS, Supabase’s authentication greatly simplified authentication, and user management .

What didn’t work:

Knowledge cutoff and lack of online resources for local LLMs are undoubtably a constraint and thought its impact will vary depending on your use-case, it forced me at times to go online to find the answers I needed.
The previous is especially true for SDKs and APIs that got major changes since the cutoff date. I need to learn more on how to get specific more up-to-date resources into local models 🤔.
Some uneducated choices of UI React components that I eventually had to learn the hard way. I found headless UI components to work better for me though they might require a bit more styling.
Supabase JS API can be challenging if you’re planning to use more complex SQL queries and the free tier understandably has no auto-backup so I one has to do it manually.

Key takeaways:

Local LLMs can be a viable alternative for certain use cases, especially where privacy and control are paramount. Mileage may vary depending on your use case but for me this was the biggest force multiplier which allowed me to build the MVP in less than 3 weeks using a tech stack I was not familiar with.
Being aware of the local LLMs’ limitations (like knowledge cutoff) is crucial to effectively work around them.
Next.js with Supabase offered a solid foundation for rapid and secure application and backend development. Leveraging managed services like Supabase can significantly reduce development overhead with minimal configuration and no maintenance overhead.

Development environment and deployment

The IDE and agentic editing

Having used JetBrains IDEs for years, I sought a simple, performant, and free code editor to develop Laburo (spend no money ramping up, remember? 💸). While VS Code is a popular option, I eventually discovered Zed and it felt much less overwhelming.

I couldn’t be happier with the decision to go with Zed and it’s become my workhorse. Though not (yet) as feature-rich as some established IDEs , it offers everything I needed: speed, performance, and support for LLM integration through agentic editing.

Integrating local LLMs into Zed, initially using LM Studio, proved challenging and involved a lot of experimentation. Models generated code with unexpected results from upside-down streams to verbose tags. Switching from LM Studio to Ollama for agentic editing has significantly improved the workflow and the results are now far more productive.

These tools are still evolving, and I’m also continually learning myself, but Zed paired with Ollama for agentic editing is starting to work incredibly well being a powerful combination for building Laburo.

Deployment

Having experience with some of AWS services and after completed studying for the AWS foundational certifications, before moving on to other more advanced ones, I was settled I would use AWS to deploy Laburo and use some other services there as well.

As I evaluated the tradeoffs between AWS and other platforms it started to become clearer that maybe AWS was not the ideal choice for me to startup Laburo.

Despite initially planning to use AWS, evaluating the tradeoffs made it clear that either CLoudFlare or Vercel was a better fit for Laburo’s current scale and the immediate future growth if it happens. After struggling to deploy my Next.js app at CloudFlare I turned to Vercel's where even the free tier made deployment incredibly straightforward. Deploying my Next.js application for the first time took just minutes thanks to its seamless integration.

Continuous integration and delivery pipelines

Initially, I chose GitLab over GitHub because I tend to prefer its more granular control over pipeline triggers, but Vercel’s seamless integration with both platforms meant I really had no need for it.

Ultimately, my needs were simple: a private repository for code, easy deployment integration, and issue tracking … all readily available on either platform.

A quick note that on the free tier a production build and deployment are triggered every time it detects a change to your main branch. This is great for continuous deployment but I fell more comfortable keeping a development branch with a working copy of the application and branch everything from it. Merging development into main triggers the production deployment 🚀.

Just remember, no matter how small your project is, always use version control … you’ll regret it sooner or later if you don’t 😉.

What worked:

My most recent experience using Zed with Ollama and local LLMs is becoming really powerful at no cost. This tradeoff works well for me compared to more advanced and expensive solutions.

What didn’t work:

While Cloudflare's free tier proved surprisingly generous, looking back, starting with Vercel would have streamlined the process and save valuable time. I was concerned about a sort of “vendor lock-in” since Next.js is a Vercel platform but that is arguably unfounded and should not even be a concern at this stage and scale of a project like this.

Key takeaways:

The power of iteration and pivoting is critical. Even though I was set on using AWS, evaluating tradeoffs revealed a better fit for the current stage and scale.
Your tooling ecosystem matters and don't be afraid to experiment with new technologies! My development environment is quite simple and somewhat new to me but the fact that all the tools and platform work and integrate well together significantly boosted productivity.
Free tiers on deployment platforms like Vercel or CloudFlare can be surprisingly powerful and sustainable. They also tend to offer sophisticated services like CDN, edge network and serverless functions which elevates the quality and performance of your platform considerably.

Reflections and lessons learned

Developing a solo project can be a very lonely place

For me as someone that worked within and led engineering teams for many years now, not having people around who you can discuss your ideas or use them as a “rubber duck” for brainstorming is an awful thing. I value when someone tells me "that’s a stupid idea and here's why…" so that we can either improve it or just move on to something else more productive … flying solo makes this much more challenging.

What I’ve learned :

It’s important to keep self-motivated. Building a solo project requires significant self-discipline and motivation and there is no team to celebrate wins with. Set realist goals when planning and celebrate small wins.
Fight that imposter syndrome. If it helps you just consider that if I could do it after more than 5 years without writing a single line of code, I’m sure you are more than capable to do it as well. And if you lack the technical background, you can now use great AI tools that can build a decently working prototype for you.
It’s easy to sit in front of your computer for an unhealthy amount of time when you’re exciting building a new thing, this is an easy way to affect your mental health and achieve nothing. Keep your family and social life going as before, travel, practice sports and envoy your hobbies. You’ll get much better results.
Apart from my family life, I found that keeping in person contact with friends, going out for a drink or dinner or even get together for a coffee helps me a lot including when discussing my project.
Don't become that person who is now a founder and can only talk about their amazing idea and project. Enjoy the time with your family and friends, and remember that most of the time they don’t even care about what you’re building, they care about you.

Be ready to pivot, always.

It doesn’t matter whether it’s a feature you’re planning or a technology or platform you’re about to use, always be ready to pivot so you don’t crash against a wall.

Remember when it looked like AWS was a no brainer to jump start Laburo? Evaluating different alternatives and their tradeoffs revealed others that fitted this use case better. And it’s not just about the technology, I wanted to build a feature that was nice but talking with a friend and early adopter I realised there was a much better and far more valuable feature I could build with the same technical approach and roughly the same effort.

These things matter because all the time you spend stubbornly refusing to pivot on something, is time you’re wasting not building the thing that matters most, a product that works for you and your users.

What I’ve learned:

Embrace experimentation and rapid prototyping. Quickly building and testing different approaches allows you to validate assumptions and identify potential pitfalls early on, minimising wasted effort.
Even when you think you know the answer, be ready to challenge it and challenge your own assumptions. It’s easy to rely on your past experience without considering alternatives which might hide a better solution from you.
Seek feedback constantly and from early on, more on this bellow but listening to feedback and being ready to pivot based on it has helped me to build a better product.

Constant feedback is paramount

The value of external feedback and setting up feedback loops early on cannot be overstated. Even informal conversations with friends, potential users, or online communities can provide invaluable insights and prevent you from going down unproductive paths.

What I’ve learned:

Consider actively seeking feedback from early on. I’ve validated my idea seeking honest feedback from friends even before writing a single line of code and I’ve been seeking that feedback at every step and every opportunity.
Seek out early testers and solicit their honest opinions. Some of the best features now on Laburo were never in my initial idea but surfaced from ideas and feedback generously offered by friends and users.
User feedback is critical to surface what challenges they are facing which might be different to yours. This information is gold and can provide you with invaluable insights on what to build next, or what not to build, on your platform.
Attend tech talks or founders gatherings or groups. I found these extremely valuable not only to interact with like-minded people but also to share what you’re building getting valuable feedback.

The joy of creation

Despite the challenges, building Laburo has been incredibly fun and rewarding. Sure, I’ve been either building software or leading teams to build software my entire career, but building your own platform ignited by your own ideas and powered by your own users’ feedback is not quite the same as building it for someone else.

I almost forgot how much fun I have solving problems through code and technology. I’ve always been passionate about my work, but building my own platform to solve my own challenges and attempt to make it a product so it can help others take this passion into a completely new level.

Wrapping it up

I didn’t learn all of these lessons just by building Laburo. I learned most of them throughout my career both as software developer and as a software engineering leader. Despite that, doing it all on your own in a solo project is not quite the same thing to what I was used to. It gives all of those lessons a completely new perspective and in some cases they are even more valuable ones.

Looking at where Laburo is now, after being released to the public only a few weeks ago, I have the feeling that building it was actually the easy part and this is the lesson I am learning now:

Starting up a product and building it is just the start, a hugely important and necessary step, but growing it to something more than a cool pet project requires skills and facing challenges I am yet to learn about and learn how to overcome. The journey continues.

A huge praise to platforms like Zed, LM Studio, Ollama, Vercel, Supabase, CloudFlare, PostHog and similar alternatives. It’s amazing how much you can get from these platforms for free and especially how much configuration and maintenance work they take away from your hands allowing you to focus on what matters the most: build your own product.