14
16 Comments

I made 7 projects in 12 months

Approx: 10 min. read

img

It's approaching the end of the first year with my bootstrapped projects and it's been quite interesting looking back at what I'd done to date. Here, I'll share the why, how and what I made, as well as learnings and what I have planned next. A summary:

  • 7 projects (mariohayashi.com/projects)
  • 6 products
  • 3 active products (IH profile)
  • 2 newsletters (that I've not been on top of as much as I should have been!)
  • 2 open-source projects [1] [2]
  • ~17 domain names (went nuts on Black Friday)
  • ~37 git repositories

All the projects are self-funded by my part-time contracting work (some of which I've documented on contracto.dev). Comments and tips welcome below!

Why?

For context, by trade, I'm a software engineer with strengths in product and design. After working as tech lead/CTO at startups and winding up a startup — despite receiving a £1M funding offer that my co-founder and I walked away from (another topic I intend to write on, in future!) — I took a little break last year to evaluate what I wanted to do next. I considered my options: jump straight back into startups in a founding role; join a pre-idea accelerator as I did before; pursue the career path (engineer at Big Co). Some sounded better than others. But ultimately, I had a strong want to simply build.

Building is what I enjoy most, creating things to see how it might turn out. To see what the reception might be. I can definitely relate to Josh Pigford's long list of projects in this sense. There's enjoyment in exercising creativity and intellectual curiosity to bring an idea to fruition. It's effectively playing. Like playing with Lego, I want to see how the different pieces fit together. Whether it's engineering, product, marketing or growth, they're all different pieces of the puzzle that you want to optimise for, for your target audience. Indie making maximises the exposure to that puzzle, so that's why I decided to focus on making things while supporting my work with software contracting.

How?

With years of product engineering experience, I've established that making a product is the easy part. For the technical among us, with each project the making part boils down to:

  • Set up AWS resources (my bread-and-butter)
  • Whip up a web/mobile app
  • Iterate on said app for set time frame until I have an MVP

Of course, I try to keep the MVP as lean as possible. For example, I made CopyOcean (incl. landing page and web app) very recently in ~1 week. I probably could have cut more corners but I figured a week is not a huge amount of time to build a working product in the grand scheme of things. I've found that building quickly is often the shortest path to "real" user feedback. Some have the gift of conveying their abstract ideas in a compelling way. For me however, I seem to express things more clearly when I "show, don't tell". As Suhail (Mixpanel founder) puts it:

Stop overthinking it. Talk to users, build it, and see what happens!

Next, after making, I try to find as many channels as possible to test the proposition. This part I'm still working on, as I find this to be one of the most difficult parts when starting out! Some channels work better than others for your target audience. There are lots of books about this area including Zero to Sold by @arvidkahl and Traction by Weinberg. Going by the puzzle analogy again, some puzzle pieces are bigger than others depending on your vertical. But finding them takes experimentation, patience and persistence.

What have I made?

Here, I list products only (I've left out blog-type "making"). Four are still active but some are now inactive. I keep this list updated on my personal website.

CopyOcean (beta)

img

Started November 2020.

Write copy in Notion, export with CopyOcean. Made for copywriters and product managers who work on web/mobile apps with developers.

I'm a big fan of Notion. I've started to see it being used at a lot of businesses. A majority of my contracting clients are heavy users of Notion. Copywriting is a natural fit for Notion because Notion makes it easy to write. I can't remember a time where writing was more fun!
While I'm all for copywriting in Notion, I felt there was something missing to get the copy into production web/mobile apps without needing to bug developers. So, I built CopyOcean very quickly to test out the concept.
CopyOcean is still in its early days (just ~1 week old), so a lot can change based on feedback. E.g. there are plans to add an API/headless CMS to it!

It's in private beta at the moment. You can try it today at copyocean.com.

Also, I use it for www.copyocean.com itself (I'm a fan of dogfooding).

Pageably (beta)

img

Started May 2020.

Pageably publishes your Notion pages as blogs, personal websites, marketing pages and more. You can add a custom domain, SEO, custom CSS and performance boosts to your Notion Pages without code.

In a slightly different twist to Super.so and Fruition (both of which are excellent products), Pageably's goal is to present your Notion Pages in any way you like.
Imagine you could have a very custom look for your blog but the content were based on Notion content. That's what Pageably wants to be. Adding custom CSS to your Notion Pages is a start, but there's obviously more that can be done!

You can try it today at https://pageably.com.

I use Pageably personally for making quick sites/blogs, e.g pageably.com itself, blog.pageably.com, help.copyocean.com, blog.mariohayashi.com and more!

See Memo

img

Started March 2020.

With See Memo, you can create custom widgets for your website in minutes. Offer helpful hints or gather feedback with simple but flexible widgets.

This was a project inspired by some of my work at my previous UX analytics startup that helped businesses gather user feedback when the user displayed frustration.
I felt a general-purpose widget builder was not available and thought it was worth testing! See Memo was also my first Product Hunt launch (wrote about here).

See more on See Memo.

Picture Cook (inactive)

img

Started March 2020.

Do you cook at home? And do you struggle with wordy, lengthy recipes? Picture Cook offers a visual alternative to textual recipes. It attempts to make cooking more fun with pictures.
This was a fun project, I really indulged in the making of it. I probably spent way too long on the React DnD drag-and-drop interface and the original artwork but that was the fun part!
It was also released on Product Hunt.
I've not been working on this project for a while now as (a) it didn't fit with many people's cooking habits (mostly only mine!) and (b) I was ready to try something new.

You can see recipes at https://picturecook.com/recipes.

Tugboat App (inactive)

Started Dec 2019.

One of the most ambitious projects I attempted in the past year, Tugboat App was an app that converted Figma designs into React components. With re-usable Figma components, it generated React components that the developer could re-use in the production web app.

The vision was to allow No-Coders and designers to create production-ready components to be inserted into web/mobile apps. The idea validation was quite positive. Designers loved the concept.
But problems emerged as Tugboat App wasn't able to produce the components at a high enough fidelity. Even with lots of thought-through engineering work, it wasn't scaling well. Maybe it's a thing for ML (pix2code variants, I'm looking at you)! There was also the problem of the 2-way sync between Figma and Tugboat App, which wasn't easily reconciled. If a developer changed the component, how could that be reconciled in Figma?
Sadly I shut the project down but I see more projects in this area, especially with ML-backed solutions, which appear promising!

Wondercask (inactive)

img

Started Nov 2019.

Wondercask was an app for craft beer lovers to find and rate beers, and navigate festivals.
I'm big on craft beer, so wanted to try a project where I could marry my love for good beer and my product/engineering skillset.

The admin dashboard I made for festival organisers was a lean MVP. After I made it in less than a week, I sent emails around for validation.
They didn't come back positive and it seemed the market was very small (not broad enough a niche), so I parked the project.

Learnings

There were loads of learnings while making these projects! I'd never flown solo like this before so there were a lot of things I needed to pick up on the go. Here are some insights that I think I'll lean on in the future:

  1. Opportunity cost: There are financial upsides to joining a Big Co and there are career upsides to jumping back into leadership at funded startups. But I've always loved the idea to build from scratch and that's where I'm finding most enjoyment at the moment, supported by software contracting. (Of course, this might change over time!) This topic gets talked about time and again (e.g. see @mijustin's thread here ).
  2. Set goals: Related to opportunity cost, know what you're trying to achieve ahead of time. It's important not only because you (a) want to know what success looks like but also (b) you want to know when to move on.
  3. Your personal brand: It's easy for this to be neglected but I've found this to be important for me as a maker (both for others' perception of me and for myself). Be clear about what you're about, define it for the public and be happy with it! For me, right now, it's software contracting, No-Code and making. @anthilemoon's Make & Shine was a good read on this topic.
  4. Balance your strengths with your weakpoints: My primary strengths lie in product/engineering/design but that doesn't mean I should build all the time. That could work in a wider team but, as a bootstrapper, that'll neglect all the other important aspects: finding, engaging with and building an audience. What I've found is that sometimes you can use your strong points to offset your shortcomings (e.g. build extremely quickly to have something to show people). Not building anything/having anything to show prior to validation doesn't work, just as building things without talking to users doesn't. It's a balance as a bootstrapper.
  5. Making is the easy part: Alluded to above and I wrote about it here. Making is, at least for me, the easy part. The hard part is identifying a need beyond your own (I often build things for myself) and spreading the word. Finding your audience and then doing customer development are hard things. Takes persistence and patience.
  6. Do your basic homework: If all you want to do is make for the sake of making, then you won't need to do this much. But if there's any intention of taking it to a wider audience, estimate your potential reach, how your funnel looks like, what drop-offs you can expect in your funnel and how many user's you can expect. E.g. out of a total addressable 2M users, 40% signing up and 3% converting will amount to 18k converted users. Ask yourself if that makes sense to you.
  7. Take regular breaks: I've started to enjoy going for walks (not only in part due to lockdowns). Indoor fatigue is a thing, so take care to get some fresh air. I take hour-long walks, when I can think about chores, responsibilities and project plans I want to keep in check. It's also ok to just take a break without thinking about anything. (Binge Netflix if you must.)
  8. A healthy balance: If you're balancing making with other things (a full-time role, contracting, etc.), it's important to know what your limit is. When I was trying to juggle five days of contracting with making during weekends, I knew I reached a limit. My head might have exploded if I did that for too long. 😅 So, I've re-balanced my time so that I have more time to make while contracting a few days a week. This has been good for both mental well-being as well as for my creative energy!

What's next?

After a year of dabbling, I'll continue on the path of making while supporting it with software contracting. Contracting has been a blessing of sorts, as I've been able to work with clients who I know well and enjoy working with (thank you!).

I'll be setting goals to add more structure to my projects. In the immediate future, it'll involve my recent projects (e.g. CopyOcean) but I will have more lined up and to look forward to in 2021, including a novel way to learn the Japanese language.

Thanks for reading. 🙏 If you have any thoughts, comments and tips welcome below!

  1. 3

    As a developer who loves programming and hates implementing design in HTML, I would happily use a Figma-to-React converter. A month ago I spent a whole day converting a Figma page into HTML/CSS. That's over 150 euros. If only I could convert it automatically one-way, I would definitely pay even for a single use.

    1. 2

      Maybe it’s time I revisited that project... It’s been a bit of time since so maybe I have new approaches for round #2 😁

  2. 2

    Woww thank you for sharing this. You are right build is the easy part. I am having a lot of problems to sell my products. This is a very weak point for me.

  3. 2

    Great read!

    I'm in a very same situation. I provide dev services part time to keep me up. The rest of the time I build side projects.
    I built a few side projects already. Only one of them is generating some revenue, nothing serious though.

    My biggest issue is distribution. Building is truly the easy and fun part as you mention.

  4. 2

    Mario, wonderful post. Thanks for sharing.

    What were some of the reasons why Tugboat wasn't able to produce React components with high enough fidelity? Even if it's just a 1-way sync from Figma to React, it seems like it would be really useful.

    Also, are there any similar apps to Tugboat that you think are doing a good job?

    1. 1

      Good question! The devil is in the details IMO.

      Tugboat worked really well for simple components. It also could anticipate responsive web for simple components. But once designs got a bit more complicated, things fell apart. For example, I had to anticipate tiny discrepancies in layout/positioning. I didn’t want to use absolute positioning from the start as that’s rarely used by humans and won’t look well across breakpoints. I used what’s called flex positioning and tried to anticipate multiple elements to be in a row if they were vertically 2-4px apart. I was trying to anticipate these discrepancies because often designers (to no fault of their own) will misplace an element and it’d result in an element being 1-4px vertically off perfect alignment. Similarly, you can create text boxes that are much bigger than the text itself in Figma (not tightly fitting the text). This caused problems with trying to anticipate whether an element is left/center/right aligned. Another problem was when these oversized text boxes overlapped with other elements; which elements should be on top? It’s hard to anticipate all of these edge cases. After trying to address these issues, I started to notice that the initially well designed compiler I wrote started to look like a monster, trying to anticipate edge cases. 😅 I realized I needed to take a step back and evaluate a new approach. (Two-way sync was to be addressed too.)

      At the time there was a YC startup trying to tackle the same problem: PageDraw. Interestingly they had their own visual editor that imported from Sketch, Figma which may have circumvented some of the issues above (and gained more control). Tugboat didn’t try to create its own visual editor (because I didn’t want to reinvent the wheel). They wrote about other problems that led to their winding up. I see new tools from time to time that output code from Figma. Whether they do the code generation to a high enough fidelity I don’t know. It’s very, very difficult IMO because humans expect 99% fidelity for things going into production. (For design prototypes you can sacrifice code quality and/or responsive web fidelity etc. which is why Figma X works well for prototyping.) It’s like ML: if a ML voice recognition software is only right 80% of the time people will dismiss it as an inferior product. But once you cross the magical threshold of 95% accuracy suddenly people will trust it and use it. This was the nature of the problem!

      1. 2

        This is super fascinating. Thanks @logicalicy. You developed great insight, and I think you were on to great problem. I hope someone solves it.

        1. 1

          Definitely find the problem interesting. And I'm convinced it needs to exist in the next 10 years (as tech evolves)! Maybe I'll revisit it in the coming year... with a new approach! (TBD)

  5. 2

    Kudos, very inspirational. Thanks for sharing!

  6. 2

    This is great to see. You've been really busy!

    I noticed that there wasn't much commentary around income or active users.

    Do any of these products make any recurring income?

    Maybe that's not currently a focus of yours, but always interesting.

    Thanks for sharing!

    1. 1

      It's been busy! 😁 You correctly point out that I didn't make mention of users or revenue. In terms of users, it's in the order of ~70 for Pageably (beta) at the moment. CopyOcean (beta) only just started so it's just a few. 🙂 Regarding revenue, I have made the first dollars online (!) but it hasn't been a focus (as much as I'd like it to have been, admittedly). That's where goal setting will come in, for the next year!

  7. 2

    Thanks for sharing and good luck!

  8. 2

    Great read, thanks for sharing Mario! I especially connected with point 5, "Making is the easy part". As someone who also has more strength on the development side, I often struggle with finding viable and consistent distribution channels. What have you found has worked the best for you so far when it comes to bettering that side of things?

    1. 1

      Thanks for reading!

      struggle with finding viable and consistent distribution channels

      It's the hard part indeed. 😁 It's difficult to say what works generally across projects, as it can vary with the audience. But, perhaps, experimenting with channels (even those that look "perpendicular" to your usual ones), keeping a close eye on where users are coming from and consistently generating content to serve that channel may be the best I can think of. But I'd love to hear your thoughts on how you've navigated this challenge @rfitz!

Trending on Indie Hackers
After 10M+ Views, 13k+ Upvotes: The Reddit Strategy That Worked for Me! 42 comments Getting first 908 Paid Signups by Spending $353 ONLY. 24 comments I talked to 8 SaaS founders, these are the most common SaaS tools they use 20 comments What are your cold outreach conversion rates? Top 3 Metrics And Benchmarks To Track 19 comments Hero Section Copywriting Framework that Converts 3x 12 comments Join our AI video tool demo, get a cool video back! 12 comments