Auteur/autrice : Elliot Boucher

  • Lesson from Middle-earth

    My wife is a The Lord of the Rings fan. Naturally, our honeymoon had to take place in New Zealand.

    While I’m not a huge fan originally, visiting Weta Workshop and Hobbiton struck me.

    Probably not for the reason you would think though.

    Dissecting Sauron’s armor, or smelling the fire inside a lovely Hobbit-hole, is super cool.

    There’s no such thing as a skinny Hobbit.

    However, what really stayed with me is the time invested to build something that lasts.

    We are hedonists and storytellers, which for most people opposes the productivity required to earn a paycheck. More often than not, working means following the Pareto principle as much as possible.

    Though like most rules, it exists to guide us, not bind us.

    Hence, when I learned that 90% of the props that are made for Hobbiton or The Lord of the Rings aren’t reaching production, it tickles me.

    It’s not « productive » by modern standards… Or is it?

    Tolkien created billions of dollars of value with The Hobbit, The Lord of the Rings, and derivatives.

    This marvel cost him a lot. More than 10 years, just to write The Lord of the Rings.

    Of course, it took thousands of people to make the movies, sell the merchandise, or build the games.

    Now imagine he’d been « productive » about it. Three years instead of ten. Would the books have been as good? Would any of the rest have happened at all?

    Naturally, if the output were the same, faster would always win.

    Building « cool stuff, » as Richard Taylor would say, takes time. More importantly, it takes trials and errors.

    In any case, it matters way less for things that scale.

    If you are reading this (thank you by the way!), you may know I love building SaaS, because it scales.

    It feels like a video game, with some luck in it as well. You can play, and play, and eventually, something is remarkable enough for people to use.

    But you know what’s more scalable than SaaS? Writing a book.

    Sure, maybe not in total possible revenue. Even J.K. Rowling won’t be close to Elon Musk.

    Still, Elon Musk has to hire and manage a lot of people to get there. A writer can get a publisher, and royalties… that’s pretty much it, if you want to handle it minimally.

    Above all, a book doesn’t need to be updated.

    You can always do some tweak, add another book, but the core of it won’t budge. Whether you like it or not.

    So why is it interesting?

    Well, I’m pretty sure we can draw a parallel between a product’s quality and its scalability. The issue is real life: you have to pay employees to develop the code, or pay yourself enough to live decently if you’re a writer.

    Therefore, one should aim to invest as much as possible, without getting killed, or living a horrible life. The goal being to create the best product possible. Whether it’s a book or a piece of software.

    Of course, software is different, because it can’t last without evolving, so the balance is harder to find. But until the product is so good it prints money by itself, investing more is probably the best course of action possible. Invest money and time: your precious.

    Attempting to build something that lasts probably won’t work the first time. It’s still worth trying.

    After all, doing business in Middle-earth might get you killed.
    Selling stuff about Middle-earth might make you rich.

    Either way, the journey is the fun part. Not everything cool lasts. But the things that last should at least try to be cool.

  • Vibe coding as a non technical founder

    I’m not a coder. That being said, I do work in tech as the CEO of a B2B SaaS and collaborate with developers daily.

    I do know many tech concepts and even took some courses in html, css, js but also C++ and Python over the years. I’m curious.

    Basically, I’m pretty bad at everything and wouldn’t be able to code something clean if my life depended on it. However, I’m not afraid of anything and can figure lots of things out if you give me some time.

    It feels like I get stuck on issues that would be easy to solve as a professional developer… But at the same time, I don’t have a curse of knowledge and just try to get things done. Which sometimes means that I can get good enough results fast.

    Here is my current point of view of Vibe Coding.

    What I’ve done with vibe coding so far

    • Deployed CRON tasks to sync a db from an API, daily
    • Fixed typos automatically in Edusign
    • Fixed lots of UI stuff in Edusign
    • Built custom apps for Edusign’s app marketplace, with external APIs and UI
    • Launched small marketing websites/experiments
    • Built a SaaS (Digital Asset Manager), working in production with auth and full features.

    Tools I’ve tried

    • Replit <3
    • Claude Code
    • Codex
    • Lovable
    • V0
    • Figma Make
    • Dust
    • Copilot
    • N8N, Make, Zapier
    • Perplexity/Claude/ChatGPT
    • And many smaller ones for specific use cases I’m forgetting.

    Things I’ve learned

    • Plan as much as possible
    • Split into small digestible bits (like a human!)
    • Treat it like a kid with super powerful powers
    • How to use Git & Github, way better
    • Many tech concepts
    • Search what you don’t know
    • Shoot your shot but don’t persist, don’t be that lazy and read some code

    What I like about it

    • Feels like magic
    • Can focus on the UX, finally
    • The UI is surprinsingly good
    • Spent 80h vibe coding in a week, wanted to do even more

    Where I struggle

    • Some things can break
    • Basics are tiring sometimes
    • Software is still hard

    What I wish for the future

    • Better sandbox/production segmentation, but easy to go from one to the other.
    • Smarter software around the LLM. I love what Replit is doing with some contextual buttons for example, way better than average in my opinion.
    • Obviously, better reasoning models

    What I shared with my team

    • Cultivate curiosity & fundational skills. It won’t be about typing the right thing, but what’s the right « way » to do it.
    • Great experience designers are going to have a great time. Average one aren’t going to be there to see it.
    • Use AI today to be ready for tomorrow. Because it’s coming no matter what you wish.
    • Claude Code is cheap compared to your salaries, stop comparing company expenses to your personal money.
    • If only 10% of the time you 10x you could go twice as fast. Yes it’s going to be wrong, often. But when it works… It’s a marvel.
    • For the non technical people ; Use AI, and learn basic tech concepts as well. If you don’t know what’s Github, a webhook, a db or an API you are going to have more surprises than you might expect.

    Controversial take

    I do think it’s possible to launch a SaaS 95% Vibe coded and have some users use it. But not just as an experiment or a PoC. A real fully working SaaS that won’t break too soon either.

    But why are all the posts on Linkedin, X or Reddit saying otherwise?

    • Non-tech people lack some technical concept to reach that possibility in the majority of cases
    • Easier for devs to shame people on this topic than to support the growth
    • The few that do it successfully don’t share it because of the previous points
    • Like every other new business, only 1% really make it, the rest is noise.

    So what does it all mean?

    Well, I’m not 100% sure to be honest.

    However, I know for a fact that even if Vibe Coding doesn’t end up being the way to code in the future, it will help the world on one very important point:

    Coding is no longer scary.

    This is the biggest deal. It’s not just true for coding by the way. The greatest perk of LLMs, in my opinion, for the average human, if used correctly, is to be able to learn faster.