The 10 year old indie mobile app: what worked for the long haul
11–18 of 18 posts
Re: The 10 year old indie mobile app: what worked for the long haul
#12... But if you are counting how long integration tests take to run in single-digit minutes then either your app is really small/simple or your integration coverage is low! :)
I've worked on "state of the art" frontends at BigCos where integration/end-to-end tests are sharded across perhaps 10 test server instances ("local" in spirit, in reality technically not on the workstation), and even then it takes 20+ minutes to execute. They typically have to execute separately from the usual unit tests etc (which run automatically as part of the pre-push CD set up).
Re: The 10 year old indie mobile app: what worked for the long haul
#13Integration tests that fire up a local server are not that unusual I find. I don't think there is anything unusual or "wrong" about that. ... But if you are counting how long integration tests take to run in single-digit minutes then either your app is really small/simple or your integration coverage is low! :) I've worked on "state of the art" frontends at BigCos where integration/end-to-end tests are sharded across…
Re: The 10 year old indie mobile app: what worked for the long haul
#14At Wyndly, we're a software-enabled allergy immunotherapy practice (https://www.wyndly.com/pages/immunotherapy). I have a background in software engineering, and I had to learn that code wasn't always the solution. Better code doesn't mean better business outcomes for us! Sometimes I say "Every line of code is a liability!", because it's now something a small team has to support forever.
Your three bullets on how to build are something I agree with so much! Arguably, this is something everyone outside of an at-scale product should build while finding product-market fit and growth channels:
- Focus on building simple solutions that solve real, urgent user problems, in well-worn ways.
- Use battle-tested software and platforms that are stable and don’t change too much over time.
- Only integrate with third parties when it’s absolutely necessary for solving those real, urgent problems.
Thank you for sharing!
Re: The 10 year old indie mobile app: what worked for the long haul
#15The older I get, the more I appreciate the value of reliable and relatively unchanging software components. Not that there isn't a place for innovation, but there's also a place for good things that endure.
Re: The 10 year old indie mobile app: what worked for the long haul
#16Taylor, I really enjoyed this post, and I shared it with my engineering team and also group chats. At Wyndly, we're a software-enabled allergy immunotherapy practice ( https://www.wyndly.com/pages/immunotherapy ). I have a background in software engineering, and I had to learn that code wasn't always the solution. Better code doesn't mean better business outcomes for us! Sometimes I say "Every line of code is a liabi…
Re: The 10 year old indie mobile app: what worked for the long haul
#17I have over 50 ios apps that are over 10 years. It is amazing how competitors come and go.
I'm curious how profitable that has been over the decade?
Re: The 10 year old indie mobile app: what worked for the long haul
#18If you can’t avoid some dependencies then put a firewall between your code and those dependencies. The firewall shields your code from changes to the dependencies.
Basically:
Your code -> Interface -> Adapter -> 3rd party dependency.
So your code depends on the interface not the 3rd party code. And the adapter implements your interface by mapping it to the 3rd party dependency.