The Hardest Thing About Building Linkeme Wasn’t the Tech — It Was This
Hey Indie Hackers 👋
I’m Julien, founder of Linkeme — a SaaS that automates social media content for founders and small businesses.
When people hear “AI + SaaS,” they assume the hardest part must be the tech: LLM prompts, infrastructure, automation, edge cases.
But honestly?
The tech was the easiest part.
I built a fully working MVP in a few weeks using GPT, visual templates, and some good backend logic.
The real challenge?
👉 Finding clarity in the chaos.
As a founder transitioning from consulting to SaaS, I faced all the noise:
Should I offer a free plan?
Should I focus on LinkedIn or multichannel?
Do I market with features or outcomes?
Should I launch now or wait for “just one more” improvement?
Every decision felt like it had 10 possible answers.
And all the advice online? Conflicting. Contradictory. Overwhelming.
What helped me break through:
1.Talking to users, not the internet
Feedback from even 3–4 real humans using the tool told me more than 100 posts ever could.
2.Deciding what NOT to build
I kept Linkeme focused. No AI chatbots. No inbox manager. Just one thing: fast, good, automatic content.
3. Selling the outcome, not the engine
Nobody buys an LLM prompt chain. They buy peace of mind, consistency, time saved.
Building a SaaS isn’t hard because of code.
It’s hard because you need vision, clarity, and the discipline to say “no.”
Would love to hear from others:
What’s been your hardest non-technical decision so far?
Thanks for reading —
Julien from Linkeme
“Deciding what NOT to build” hit hard because I learned that one the expensive way too.
I spent 13+ years in product teams where there was always some form of decision scaffolding around you, retrospectives, stakeholders, metrics reviews, people challenging assumptions. Solo founding removed all of that overnight.
What changed things for me was treating product choices as hypotheses instead of backlog items. Not “build feature X,” but “I believe this change will increase signups by Y because of Z.” Then revisiting the reasoning a few weeks later instead of relying on memory and vibes.
I realized half the chaos was not the decisions themselves. It was having no record of why I made them in the first place.
Curious whether you document those tradeoffs anywhere now, or mostly keep them in your head.
That last line is the whole thing for me: the chaos was never the decisions, it was having no record of why I made them. Past me looks like a stranger after three weeks.
I kept everything in my head for way too long and paid for it. What I do now, imperfectly:
- I write the reasoning into the commit message and a running decisions log. Not just what changed, but what I believed would happen and why. Same framing as you, the hypothesis instead of the task.
- I instrument the behavior tied to the bet, so the answer comes from data later instead of memory. If I claim "this will lift signups," I'd better be able to actually see it weeks later.
A concrete recent one, and it's exactly your "deciding what NOT to build" point: two people dropped off at the same onboarding screen and my hands itched to redesign it. Instead I wrote down "n=2, this is noise, do NOT touch it, here's the exact metric that will tell us when it's real," and moved on. A few weeks earlier that would have been a vague memory, I'd have shipped a pointless redesign, and I'd have destroyed my ability to even measure it.
The surprise benefit: writing the why down kills half the bad ideas before they get built. If I can't articulate the hypothesis, it usually wasn't a decision, it was a vibe.
"it usually wasn't a decision, it was a vibe" is something we are seeing more and more now days, right? Because AI has made execution so fast (similar to the "itch" that you described) that we have stopped to think (maybe just for a small moment, even).
But cool that you have this decision log! A few weeks or months later, do you have any process for going back to those decisions and comparing what actually happened against what you expected? Asking coz I've found it's surprisingly easy to capture the reasoning and still lose the learning.
You nailed the exact thing I kept getting wrong: capturing the reasoning felt like the work, so I'd stop there and quietly assume the learning would take care of itself. It never did.
And yes, total agreement on the AI point. The itch and the speed are now the same problem. Execution used to have just enough friction to give you a half-second of doubt. AI removed the friction, so the only thing left standing between a vibe and a shipped feature is whether you wrote the bet down first. The log became my friction on purpose.
How I try to actually close the loop, still rough:
- Every decision gets a check-back date the moment I write it. Not "review someday" -- a real date tied to when the metric should have moved, and it goes in my calendar, not a doc I'll never reopen.
- On that date the question is binary: did the thing I predicted happen, yes or no. If yes, why do I think it worked. If no, was the bet wrong or just the execution. Three lines, done.
- The verdict gets written back next to the original hypothesis, so the decision and its outcome live in the same place. Re-reading old bets with their verdicts attached is the thing that actually retrained my instinct, more than any single decision did. Where it still leaks: the bets I never assigned a date to. Those are exactly the ones I lose. So the rule lately is blunt
- no check-back date, not a decision yet. Same bar as "no hypothesis, not a decision."
But honestly you're poking at the part I'm least confident about. Capturing is basically solved for me; the going-back is still mostly discipline held together with calendar reminders.
That last sentence, about being held together with calendar reminders, is so interesting! I feel that's where a lot of us founders end up. We build systems for recording decisions, but the learning loop still depends on remembering to come back later.
What's funny is that while the original decision is usually important enough to document (that is why we spend time writing it down), but the review ends up competing with a hundred other things.
Have you noticed any patterns in the decisions that actually get revisited versus the ones that quietly disappear? My guess is the bigger strategic bets survive, while the smaller product and growth bets get lost here and there.
great to see someone thinking and talking to users
This really resonates, Julien — especially the bit about clarity in the chaos. As someone also building solo (my project’s a web-based emoji composer for kids and educators: https://ezc.jellypie.co.uk), I’ve found the technical side to be surprisingly manageable — but carving out a clear value proposition and saying “no” to feature creep? Brutal.
I love your framing around selling the outcome not the engine. Too many of us get caught up in talking about the cleverness of the tech stack, when what people actually want is a reliable result and one less thing to think about. Your “just one thing” mantra really hits home.
Big respect for sticking to the core and resisting the AI feature bloat. That discipline’s rare.
As for hardest non-technical decisions — for me it’s pricing. Balancing accessibility with sustainability is a tightrope walk when you’re charging $1/month and still trying to build something people genuinely value.
Following Linkeme’s journey with interest — you’ve got your head in the right place.
Love this, Julien — totally agree that clarity and focus are harder than code. Saying “no” is a superpower. Great job with Linkeme! 👏
I completely agree. When I started filtering out the noise and prioritising my actual users and what they needed, it made everything much simpler and focused.
Totally agree-the tech is usually the easier part. For me, the hardest was figuring out who exactly to serve and sticking to that, instead of trying to be everything for everyone. Saying “no” to cool ideas is way tougher than coding. Also, hearing real user feedback early helped a ton, just like you said.
Also, some of your CTAs on your landing page are in French while the entire site is in English and the site overflows horizontally.
Deciding to focus on one marketing channel rather than trying to do multiple all at once.
Hi Julien,
I am excited about Linkeme and I believe it is a really useful tool for entrepreneurs and small business owners. I am a supply chain analysis student with engineering and research background and I would love to explore ways to collaborate with you on your project.
I agree that the tech isn’t necessarily the hard part. I think the hardest part for what I’m working on is going to be finding those first few users. How did you get your first customers?
People always think that building something is difficult specially when they come from a non-technical background. Dealing with tech is the easy part, dealing with "human stuff" is always the hardest.
I've been saying that for years already.
Loved how real this was, Julien. I’m a beginner building small tools with React and Flask, and I constantly feel that ‘just one more feature’ trap. Thanks for reminding me to focus on clarity over code
🔥 This really hit home, Julien. Totally agree — tech is rarely the bottleneck, especially with how fast tools like GPT let you prototype now. It’s the clarity, focus, and user feedback that build traction.
I’m building CompliAssistant — an AI assistant that helps small teams stay on top of HIPAA, SOC 2, GDPR, ISO27001 and other compliance frameworks. The hardest non-technical decision so far has been figuring out how much structure to give users vs. how flexible to keep it. Still learning a ton by iterating directly with early users.
Appreciate your transparency — this kind of insight is gold for early-stage builders. 🙌
Thanks for sharing, it's really let me though, what i need to concentrate !