I went from knowing zero Linux commands to building my SaaS in public
A week ago, I couldn't tell you what chmod did. I'd never developed on Linux, never configured a web server, and never imagined I'd be spending hours inside a terminal trying to figure out why a file refused to save.
Today, I'm building Featly on Linux Mint.
Featly is a product analytics tool that helps SaaS founders understand which features users actually love, which ones they ignore, and which ones contribute to retention—all without forcing them to dig through complex dashboards.
The funny thing is that building the product hasn't been the hardest part.
The journey started with an idea and a dashboard. I wanted something clean, simple, and easy to understand. Then reality hit. A dashboard without data is just a pretty interface, so I had to stop thinking about the UI and start building the foundation first.
That meant setting up Linux, installing XAMPP, configuring PHP and MySQL, solving permission issues, debugging form submissions, learning how file ownership works, and getting comfortable with a terminal I had barely touched before.
Some days I felt like I spent more time fixing my environment than building my product.
Eventually things started clicking. I got XAMPP running, connected everything to MySQL, fixed my email submission system so it actually stored data correctly, and recently finished the login page. They're small milestones, but every completed feature makes Featly feel less like an idea and more like a real product.
At the same time, I realized something almost every founder eventually discovers: building is only half the job.
You can spend an entire day shipping features and still have nobody know your product exists.
That's been my next challenge.
I've started documenting the journey publicly on X. Right now the audience is tiny. Some posts get only a handful of impressions. The only likes on a few of my early posts came from my main account and family members. It would be easy to look at those numbers and think it's pointless.
Instead, I decided to treat marketing like engineering.
Rather than posting randomly and hoping something works, I'm running an experiment. Every evening at exactly 7:15 PM, I publish one text-only post about building Featly. No hashtags. No changing the format every day. Every post gets a full 24 hours before I record the results. The goal isn't to go viral overnight. It's to collect data, stay consistent, and learn what actually works before I start changing variables or trying X Premium.
One thing I've learned already is that consistency is harder than motivation. Motivation gets you excited for a day. Consistency gets you to ship when nobody is watching.
I have no idea where Featly will be six months from now. Maybe I'll have paying customers. Maybe I'll still be debugging code at midnight. Maybe my X account will finally have people who recognize the name when it appears on their timeline.
What I do know is that every login page, every bug fix, every terminal command I learn, every post I publish, and every conversation I have with other founders moves the project one step forward.
I'm building Featly in public because I want people to see the entire journey—not just the launch, but everything that happens before it.
Maybe one day someone will discover Featly and scroll all the way back to this post. If that happens, they'll see exactly how it started: one Linux command, one bug, one feature, and one post at a time.
@Sengoraku Founding member cohorts are a smart starting point. Getting a group willing to install early means your feedback loop is much tighter than typical early access. Are you planning to keep them on a specific track, or letting use patterns guide where Featly evolves first?
Thanks! I’m leaning toward letting the feedback guide the direction rather than locking the cohort into one specific track.
I have a general roadmap, but I want the founding members to have enough influence to shape what Featly becomes.
Going from zero Linux experience to configuring a full stack in a week is the kind of learning pace that only happens when you're building something you actually care about.
The bit that stood out: "a dashboard without data is just a pretty interface." Most people spend months on the pretty interface. The fact you caught that early and pivoted to the foundation first is a sign you're thinking like a product person, not just a developer.
What's your plan for the first 10 users? Featly sounds like the kind of tool SaaS founders need once they hit their first 100 paying customers and start wondering which features to build next.
Thanks! My plan is to start with a small group of founding members who are willing to install Featly and give honest feedback. In return, they get to influence how the product evolves from the very beginning. Right now I'm focused on making setup so simple that getting started takes minutes, not hours. The goal is to help founders build what users actually want instead of spending weeks on features nobody ends up using.
I think building in public is one of the fastest ways to learn because every mistake gets exposed quickly. Looking back, was there one feature or decision you spent weeks on that you later realised nobody actually cared about?
Definitely. The biggest one was building a beautiful analytics dashboard before I had any data to analyse. It looked great, but I realised it solved nothing without real events. That changed how I think about building—validate the foundation first, then polish the interface
The “treat marketing like engineering” part is really good. Running a fixed daily experiment at the same time every day is smarter than most people posting randomly and then deciding “X doesn’t work.”
Consistency over motivation is the real filter. Looking forward to seeing what the 7:15 PM posts teach you after a few weeks of data.
I appreciate that. It can be disheartening to put time into a post and see only 5 views. That's exactly why I'm running this experiment. I'm treating marketing the same way I treat development: change one variable, keep everything else constant, and measure the results over time instead of relying on gut feeling. Hopefully, after a few weeks, I'll have real data instead of assumptions
The folders example is probably the most interesting one here.
Users gave you the problem (“organize files better”), but not necessarily the solution — and some apparently wanted search instead. What would you need to see now to know folders were actually the right interpretation of that need?
That's a great question. Right now I'd want to see whether teams actually find folders instead of relying on search, and whether organizing files changes retention. That's exactly the kind of product question I'm trying to help answer with Featly.
That makes sense. Have you seen any early behavior from teams that points one way or the other yet, or is this still the main question you're testing with Featly?
Still the main question I'm trying to answer. My hypothesis is that the features users return to and the ones they ignore will tell a much clearer story than any survey can . The goal is to help founders make product decisions based on actual behaviour, not guesses.
That makes sense. The difference between what users say and what they repeatedly do is often where the harder product questions appear.
I’d like to continue the conversation outside the thread. What’s the best email to reach you on?
Thanks! You can reach me at [getfeatly.app@gmail.com].
Looking forward to continuing the conversation. I'm still in the early stages of building Featly, so I'm always happy to exchange ideas with other founders.
Thanks! I’ve just sent it over.
Looking forward to hearing your thoughts whenever you have a chance.
The insight about treating marketing like engineering is gold - you're literally running an A/B test (the "7:15 PM consistency experiment") that most founders would never think to structure. Most people just post randomly, get no traction, and assume "X doesn't work." But you're the one running the actual experiment. And "consistency is harder than motivation" is the sentence most founders skip over but is the real differentiator. Motivation is a feeling. Consistency is a system. Building Featly on a stack you just learned shows something crucial: the right founder can learn infrastructure as fast as they ship. The infrastructure debt isn't actually slowing you down - it's building character and giving you stories nobody with managed platforms has.
The "consistency is a system" line is something I'll probably remember for a long time. I'm treating building and distribution as two products I have to improve every day. Because at the end a product is only as good as it was advertised