Ask HN: Failed launching my SaaS as a Student. Should I open source "bad" code?
I am a senior CS student. For 20 months, I worked as a solo Software Engineer at an outsourcing firm. During that time, I built several internal tools for them (never got paid for them cause they suck like that), including a clocking/activity tracking system.
I saw potential in the tool, particularly for BPOs in the MENA region (I am there). I spent the last 6 months rewriting the architecture for multi-tenancy, overhauling the UI/UX, and adding productivity and compliance algorithms.
I recently attempted a launch. It was silent, and frankly, a failure. I realized two things:
- My market research was too reliant on LLMs and lacked real-world validation.
- I do not have the resources (time, capital, or connections) to compete in the saturated "Time Tracking" market while finishing my degree or learning some actually useful job skills.
Now I am faced with two options, holding on for it longer and just shelving it with the excuse that maybe I get to build something around it which brings it back to life, or, Open Source it and share the code (definitely not sure about the quality of code and architecture and didn't care for the most part because I was trying to accelerate the launch) and try and get probably brutally roasted for it.
The whole Idea is to fail forward, so I am asking for both feedback and advice from more experienced peers.
You’re a student. Open sourcing the code for portfolio purposes is a good idea, whether or not the code is great.
Entry level engineers on their own are not expected to produce flawless code let alone architecture. That you achieved something that ambitious in the first place will be a mark in your favor for most hiring managers.
Just check your contract and IP agreements first to make sure you actually have the right to use the code, since the way you’ve phrased it makes it sound as if you adjusted the company’s code rather than rewriting it from scratch after your role with them ended.
[dead]
You could open source it and continue to work on it as a side project and main thing in your portfolio to demonstrate your skills.
And over time you could even offer a hosted/paid SaaS option, if there seems be interest in that and you have more time and resources available to sustain that.
From the perspective that you'd refine this project over time (as you already have), I don't think you should worry too much about how the code and architecture look and are right now or people's reactions to their current state. It'll grow, change, and improve as you do. And others' reactions can help you grow.
> I spent the last 6 months rewriting the architecture for multi-tenancy, overhauling the UI/UX, and adding productivity and compliance algorithms.
Separately, I think it could be really good for you and your career to document somewhere online (even just a blog) some of your thinking/decisions regarding these spaces. And it doesn't need to be too formal, just lay out your thinking.
Your post here is pretty great as an example of your communication skills - which I've heard are highly appreciated/valued in CS -, so you've got the skills, and it'd be great for you to have more public proof of that.
Thank you for your feedback and I would love your take on something, does it make sense to try and do that blog series to for example build a reputation for an agency or a company?
Like we at ACME changed X on Y because 123 and so on.
Or focus this on my personal branding instead?
Just focus this on your personal brand.
You can still relate it to concerns/business requirements or processes that agencies might have, which you considered and factored in when you made design decisions about the code, architecture, or processes. But since this is more of a project that you built on your own and one that you own, it makes more sense to me that you'd present this as "I changed X on Y because 123" and so on.
I meant trying to use it to produce content to kick start my own agency, even if it's just me in the beginning, to try and get some reputation or credibility.
Oh, sure. You might be getting ahead of yourself with worrying about that at this stage, but maybe eventually.
You can do both. Make it public, and it’ll be something to point to for job interviews in the future. Frankly, if it didn’t get interest as a business, the codebase won’t either, so you can still have it for a time when you may want to build on top of it.
[dead]