A few months ago I started building my first Shopify app, True2Size: Chart & Recommender. It’s a tool that helps clothing stores create size charts and recommend the right size to their customers.
I’ve recently started seeing my first real signs of success. Merchants are installing the app, people are actually using something I built and I’ve had some really interesting conversations with store owners along the way.
I’m obviously still very early in the whole process, but I wanted to share a few philosophies I’ve had since the beginning that I think have helped me a lot. And also some things I wish I’d done differently.
My first philosophy was to build something that could do everything my competitors could do, and more.
Before I started building, I spent a ridiculous amount of time looking at existing apps in the same category. I tried pretty much everything I could find, looked at their features, how their interfaces worked and what merchants were complaining about in reviews.
And instead of picking one competitor to improve upon, I wanted to take the best parts of all of them and combine them into one product.
If competitor A had a feature I really liked, I wanted that functionality in my app. If competitor B had a completely different approach to something that worked well, I wanted to offer that too. And wherever I thought something could be done better, I wanted to improve on it.
The idea was pretty simple. I wanted a merchant to be able to recreate whatever they had already set up with another app, but then have even more possibilities available to them.
In my head, this would remove one of the biggest reasons not to switch. Why would someone stay with their current app if they could do everything they were already doing, plus more, potentially for a better price?
Obviously that’s not exactly how it works in reality haha. People value familiarity, trust and not having to spend time switching software. But as a mindset for building the product, I still think it was really useful.
It forced me to look beyond what I personally thought was necessary and understand why different competitors had built certain features in the first place.
My second philosophy was that the app should feel like it was made specifically for every merchant who installs it.
I know that sounds a bit unrealistic, and to some extent it probably is. But that’s always been the mindset I’ve tried to have.
Every merchant runs their store differently. They have different products, different preferences and different ways they want things to look and function. I didn’t want someone to install my app, realize it almost does what they need and then have to compromise because a certain setting or feature is missing.
So whenever someone installs True2Size, I try to get in touch with them. I offer to help set everything up, sometimes through a call, and ask them what would make the app perfect for their specific store.
And I actually try to do something with those answers.
If someone needs a feature that isn’t there yet, I’ll look into adding it. If something is confusing, I’ll try to make it easier. And if I notice multiple merchants struggling with the same thing, that immediately becomes a priority.
I also have a habit of writing down literally every idea that comes into my head. Doesn’t matter if I’m working on the app, walking somewhere or lying in bed. If I think of something that could make the product better, I write it down.
And if I genuinely think it’s important, I try to implement it as soon as possible.
I’ve basically been repeating this process for months now. Build something, let people use it, listen to what they need, improve it and repeat.
But there’s a problem with building this way that I didn’t really expect.
At some point your app starts becoming a bit of a mess.
You keep adding features, settings, options and little exceptions for different use cases. And while every individual addition makes sense, eventually you end up with an interface that has way too many things going on.
This is where I think a completely different kind of work begins.
Instead of adding more, you have to start removing things. Or at least removing unnecessary complexity.
You start combining settings that belong together, reorganizing features, simplifying the interface and figuring out how to make all those possibilities feel like one simple product.
And honestly, I think this is one of the hardest parts of building good software.
It’s relatively easy to make something with very few features look clean and minimalistic. It’s much harder to build something that can do a hundred different things while still feeling like anyone could figure it out in a few minutes.
That’s what I’m trying to achieve with True2Size. I want merchants to have the freedom to configure everything exactly how they want, without feeling like they need a tutorial just to get started.
I’m definitely not fully there yet, but every time I simplify something without losing functionality it feels like a bigger achievement than adding another feature.
Something else I’ve learned is how valuable it is to personally help your first users.
Especially when your app has quite a few settings, don’t just expect everyone to figure everything out themselves.
Offer to set things up for them. Jump on a call, walk them through the interface and actually watch where they get confused.
I still offer this to new merchants, and those conversations have probably taught me more about improving the app than anything else.
Sometimes you’ll discover that a feature you thought was really important barely gets used. Other times someone will ask for something that seems so obvious afterwards that you can’t believe you didn’t think of it yourself.
And that’s exactly why I think getting real people involved as early as possible is so important.
Now for the things I wish I’d done differently.
My biggest mistake was waiting too long before properly marketing the app.
I was so focused on building the perfect product that I kept telling myself I wasn’t ready to start promoting it yet.
There was always one more feature I wanted to add, one more thing to fix or one more part of the interface that didn’t feel quite right.
Looking back, I think I should’ve started getting people to try it much earlier.
Because the reality is that the perfect product doesn’t exist. And even if you think you’ve built one, the first person who actually uses it will probably find something you never considered.
You need those people to make the product better.
Another thing I’d recommend is trying not to lose momentum. I personally try to never go more than three days without working on the project in some way. It doesn’t have to be a full day of coding. Sometimes it’s just fixing something small, answering a merchant or writing down ideas.
For me, once I stop working on something for too long, getting back into it becomes much harder. Keeping that momentum has helped me a lot.
And probably just as important is learning how to prioritize.
Not every idea needs to be built immediately. Even if it’s a great idea. I’ve definitely wasted time working on things I was personally excited about while ignoring things that would’ve made a much bigger difference to actual users.
I’m trying to get better at asking myself what will have the biggest impact before deciding what to work on next.
One last thing about perfectionism.
I actually think being a perfectionist can be a really good thing when building software, as long as you’re perfectionistic about the right things.
If you’re going to build something, build it properly. Think about how it’ll work six months from now, not just whether it works today.
Spending a little extra time making something reliable and easy to maintain can save you so much work later.
But don’t confuse doing something properly with needing everything to be perfect before anyone can use it.
That’s probably the biggest lesson I’ve learned so far.
I’m still figuring out a lot of this myself and I’m sure I’ll look back at this post in a year and disagree with some of my own advice haha.
But seeing something that started as a random idea slowly turn into a product that real businesses are using has honestly been one of the most satisfying experiences I’ve had.
I’m curious how other developers approach this. Do you try to make your product as customizable as possible, or do you prefer keeping things simple even if that means some users won’t get exactly what they want?
And for people who’ve been building SaaS products for longer, at what point did you realize you needed to stop adding features and start simplifying what you already had?