29
38 Comments

Make Small Apps

I’m finding myself more and more attracted to the idea of building small apps as a solo dev.

I work full time for a company I love, but I will always make things on the side. In the past, this has meant building large scale applications, the kinds you would normally expect to find working at a startup. Graphite Docs was my first. It started small, then it grew into a complex, permissioned, encrypted collaboration platform. I then built a blogging platform and a finance app. I’ve built dozens of apps, many of which were probably too large of a scale for a solo dev.

I’m now building Perligo, and I can see the writing on the wall. If I listen to my backlog, this thing is going to grow to be too big, too complex for me to manage as an indie. I have not yet launched out of alpha, but I am happy with the product now. My former MFA cohort uses the app and is happy with it. So, this means I might just leave it alone, even at the risk of it not being something people will pay for.

I’ve started working on smaller apps. I have a new one on iOS and macOS coming out soon. I feel like the constraints of small apps are better suited to indies, but the upside is, as you’d expect, much smaller.

Wonder how you all feel about this?

  1. 3

    Did you make some profits from the software you've written?

    1. 1

      With Graphite, everything was open source and I didn’t try to monetize until close to the end. But I made a good amount on grants to fund its development.

      For Write/Sprint, a desktop app I built, I’ve made some profit. That’s the one I’m re-building as a native iOS and macOS app.

      Everything else has not made any money. Perligo has potential when I release it, but as I mentioned, I don’t want it to grow into a large scale app.

      1. 5

        Not sure how you feel about it, but for me unprofitable products exhaust the passion to make new products. I've decided to stop doing that and focus on finding pmf before writing a single line of code. If you feel the same - read "the mom test"

        1. 1

          I've read The Mom Test three times now. I love it! I applied it to my last startup. That said, I've found it difficult to apply to indie projects. That's probably a bit of a cop out, but when you are limited in time for side projects, it feels really difficult to go through the whole Mom Test process.

          Have you found that to be true as well?

          1. 2

            I split my time 50/50 between freelance and roaming around with experiments. This gives me enough time to try new things. Right now I'm actively using the mom test on reddit and hacker news :)

            1. 2

              Very cool! I hope it works out. I think part of my side project problem is building too many things just for myself. Next thing I build, I’ll try to apply the Mom Test and the lesson from Rob Walling’s book, Start Small, Stay Small.

              1. 2

                Added to my reading list! Thanks! Good luck 🍀🍀🍀

            2. 1

              This comment was deleted 2 years ago.

              1. 1

                Reddit is one of those places I really wish I had paid more attention to in the early days. Feels like it’s impossible to get enough Karma to post. But maybe DMs is is solid alternative.

  2. 2

    Interesting also in the greater context of all the talk of how network effects in the digital sphere more or less doom every digital platform to either become a monopoly or die out.

    Smaller applications will continue to grow in popularity. I feel like Big Tech might have become too focused on finding "the next big thing" while indie developers have the freedom to execute whatever they are passionate about. Millions of niche users will be thankful!

    1. 2

      A huge competitive advantage is being able to sustain yourself (and your business) on a significantly smaller ARR than big tech.

  3. 2

    Makes sense, when I start projects I have a bigger vision in mind but I will start with a very small scope and there's nothing wrong with leaving something at that size if it's solving a problem or the bigger plans don't make sense / are too big.

    I have a stash of ideas that I immediately discarded because I knew even the smallest MVP would be too big, I might wanna tackle those at a later date if I have enough time / resources

    1. 2

      I love the app idea list. I have one of those two, though I don't stash ones that I think are too big. I probably should so that it's a little more organized and prioritized toward smaller apps.

      1. 2

        ORDER BY effort also works 😛

  4. 2

    I've come to the same conclusion.

    Design, UX, scaling, support for multiple devices, security, customer support etc... so many things to consider.

    The cool thing with mobile apps is that they restrict many of the choices and have guidelines & best practices i.e iOS/macOS

    Then there's customer expectations. Web apps are usually more feature rich whereas mobile apps are usually designed for 1-2 core tasks,

    Lastly, for me it's always exciting when building a new mobile app and i can't say the same for web.

    1. 1

      I just built my first SwiftUI app for iOS and the experience was fantastic. I hope to release it in the next few weeks after testing. I agree, it was nice not having to make so many design decisions related to screen size.

  5. 2

    I did it too. First because it's too hard to have full time work and build another big thing at the same time. Second it's more fun and requires less people in the long run which I'm aiming for.

    Although, my current project was suppose to be small initially, but as I kept building it grew quite a bit.

    1. 1

      I think as long as it’s manageable still, it’s ok if the project grows organically beyond what you had designed for. But the key is having an intentional target of how big you want your app to be at the start. Congrats on the growth!

  6. 2

    Really good points.
    I created a really small product called tinyads.io.
    It's was written in less than 80 hours total for a small specify use case.

    Most features are not built and I launched this week with a minimal set of functions.
    The amazing thing is that I have over 200 users and over 30 active ads right now.
    So instead of building a big thing I decided to grow slow and build things tiny.
    It's just a side project for now.

    1. 1

      This is awesome! I remember some posts early on talking about Tiny Ads. Nice work!

      1. 2

        I'm thinking about writing a blog post with the title "Slow Growth".

  7. 2

    Working on a large scope project - for my skillset - right now and while I feel it's worth it because I've been validating / designing it over a number of years in my career, it's still quite a daunting endeavour as a solo dev. My next project will be much smaller in scope so I can get a better sense of accomplishment and progress being made.

    edit: That said, I am absolutely stripping down my current project to the smallest possible set of feature that would be valuable to my users. Every day I think of features that will be needed... but most of them can wait. Practicing this is another way to help reduce scope of any project.

    1. 2

      I come from a customer and product background. Before I learned to code, I worked directly with people, and I saw that most things that get built are delivering too many features and not enough solutions.

      And yet I still allow scope creep to impact my development work. So I feel you on the struggle!

      1. 2

        I think the only real way to avoid it is by setting up a rigid feature backlog that gets reviewed via some product management prioritization process (complexity, value, etc). It also helps give a sense of having “done something” with the feature idea simply by recording it.

  8. 2

    It's too easy to get sucked in to keep building

    And too easy to take on a project too big

    Or not notice flaws and issues that would make the project a black hole

    But also when building is "done" you still have a lot of work marketing the project and such

    1. 2

      This is probably the key insight. Even if you build small apps, you need to shift the work that would have otherwise gone into more features into marketing and selling.

  9. 1

    That is an extremely clean feeling landing page. I find that very inviting as someone interesting in reading more about what you do

    1. 1

      Thanks so much, Drew! You just made my day!

  10. 1

    This is really true. When you constrain your scope to be smaller, you end up producing a higher quality product. The worst apps are always the ones trying to do too much.

    1. 3

      I agree. One of the nice things about smaller scope apps is the clarity of focus.

      Getting users to stick to your app requires a mental trigger for "when" it is time to use the app. This helps our users build the association between a certain situation and using our solution.

      An example with a physical product is when I want to make coffee, I need to get the kettle boiling for hot water.

      1. 1

        I love thinking about software in comparison to physical products. It reminds me of the days when we had to install a floppy disk or CD to use a piece of software.

    2. 3

      Definitely agree! I think of apps like Bear (the markdown writing app), and how nice it is despite not being a huge CMS. I think that illustrates the point well.

  11. 1

    I'm also attracted to the idea of working on smaller apps. Less to maintain. I think a lot of smaller apps have an easier time finding product-market-fit. I also think they are easier to trade hands once the original developer is no longer interested, something I've started writing about.

    1. 1

      This is a good point that I had not thought about. I think this can apply in sales as well as just transferring maintenance of an app.

    2. 2

      This comment was deleted 2 years ago.

      1. 1

        I think both scenarios are solid. Small that naturally grows big is totally cool if that’s what the founder(s) want. On the other hand, staying small because you want the app to remain a side project can be smart too. As you said, it’s all about conscious decisions.

  12. 1

    This comment was deleted a year ago.

    1. 2

      That's amazing! Really nice work. I love the way you're using your blog to educate but also as a potential acquisition channel.

      1. 2

        This comment was deleted a year ago.

Trending on Indie Hackers
How I grew a side project to 100k Unique Visitors in 7 days with 0 audience 49 comments Competing with Product Hunt: a month later 33 comments Why do you hate marketing? 29 comments My Top 20 Free Tools That I Use Everyday as an Indie Hacker 15 comments $15k revenues in <4 months as a solopreneur 14 comments Use Your Product 13 comments