Lessons Learned from Building Mobile Apps and Software for Startups

Having had the pleasure of working on a healthy variety of projects both as an independent consultant and through agency work, I've gained some valuable insights into the challenges and opportunities of building software products, especially mobile apps, for startups.

I enjoy sharing these lessons to help others navigate the process and set their ventures up for success. Early last year, I hosted a workshop at The University of Bath, exploring these essential lessons with my good friend Steve. The workshop was for students in the Enterprise Bath department, and I look forward to hosting another this year.

As someone who specialises in mobile app development, I've seen firsthand how mobile products present distinct challenges for startups. From navigating app store guidelines, tackling performance issues and crafting exceptional user experiences to integrating features like offline functionality, building mobile apps requires a thoughtful and strategic approach.

Before Building Software

Before writing a single line of code, it's crucial to ensure your idea is solving a real user problem. This is especially true for mobile apps, where users are quick to delete anything that doesn't provide immediate value. Skipping this stage is one of the biggest mistakes startups make.

1. Understand Your Users

You must talk to your customers. Use methods like interviews, surveys, and focus groups to learn:

• What problems they face.
• What they currently use to solve this problem - it's often a surprising mix of apps, screenshots, and notes!
• What frustrates them about the existing solutions.
• How much value they would get from having this functionality in their pocket.

💡 Pro Tip: Instead of asking hypothetical questions like "Would you use this?" ask about historical behaviour. For example:

• "When was the last time you faced this problem?"
• "How did you solve it?"
• "What did you like or dislike about your current solution?"

💡 Pro Tip: When researching mobile users, focus on context of use. For example:

• Are they likely to use your app on-the-go or at home?
• Do they need offline functionality?
• How much time will they spend in the app during each session?

2. Break Down and Validate Assumptions

Every product idea comes with assumptions, and testing these early can save time and money.

For example, consider a "Cooking Satnav" app - an idea we discussed during the workshop. This app converts recipes into step-by-step audio instructions.

Some assumptions to validate might include:

• Users want a hands-free cooking assistant. Test this by observing whether users struggle with recipes while cooking. Is this solving a problem that may not exist?
• AI can accurately parse recipes. Use existing AI tools to test feasibility before building a custom solution.
• Audio instructions are effective. A simple pre-recorded demo could help gather feedback and validate whether audio instructions are effective at keeping users on track.

By validating these assumptions one at a time, you reduce risk and ensure your efforts focus on solving real problems.

What to Build First

Once your assumptions are validated, the next step is deciding what to build first. Mobile app development has additional constraints such as performance considerations (particularly on low-end Android devices), designing smooth and accessible user experiences on small screens, handling fluctuating network connectivity and app store approval, to name a few.

Here's how to approach this strategically:

1. Start Small

Start with the MVP and limit your initial feature set to the essentials. If building a mobile app, don't aim to implement every feature under the sun for your users. Instead, aim to deliver a small set of essential features very well.

Ask yourself:

• What is the smallest version of this product that delivers value?
• Which feature addresses the most critical user need?
• Can you delay implementing nice-to-have features like notifications until later?

💡 Example: For the Cooking Satnav, you might start by testing just the AI's ability to parse recipes or the usability of the audio instructions, based on which assumption is riskiest.

Mobile apps have unique considerations that can drive what to build first:

• Offline mode: If your users need the app in areas without good connectivity, consider offline functionality early. I'll dive into developing offline-first React Native apps in a future post, so watch this space.
• Push notifications: Notifications can help keep users engaged and nudge them toward key actions, but they need to be timely and relevant. Plan how notifications will fit into the user journey early, and ensure they don't overwhelm or frustrate users. Consider whether notifications are essential in your MVP.
• Performance: Mobile users expect fast load times and smooth navigation. Start with lightweight features and optimise for responsiveness. We'll revisit performance when discussing common pitfalls to avoid.

2. Focus on Risks

Tackle the riskiest or most uncertain parts of your idea first. For our Cooking Satnav example, these might include:

• Technical risks: Can the AI handle recipe parsing?
• User risks: Will users find the step-by-step format helpful?

3. Generate Feedback Early

The goal of your first version is not to impress but to learn. Launch quickly, gather user feedback, and iterate. Publishing a mobile app, even an MVP, can involve delays from app store reviews. Use platforms like TestFlight or Firebase App Distribution to share test versions with users.

How to Build It

Building software effectively isn't just about writing code - it's about using processes that enable rapid iteration and high-quality output.

1. Use Continuous Delivery

Keep your software in a releasable state by:

• Making small, incremental changes.
• Testing thoroughly before merging code.
• Using tools like GitHub Actions or CircleCI.

Keeping a mobile app in a releasable state at all times can be tricky with app store submission cycles (Google Play reviews can take well over a week in some cases), but tools like Bitrise and Fastlane can automate much of the release process.

2. Automate Testing

Automated testing ensures your code works as intended and helps to mitigate against regressions. For web applications, tools like Jest for JavaScript or Cypress for end-to-end testing can save hours of debugging.

Mobile testing requires special attention to platform-specific issues:

• Use tools like Detox or Appium for automated testing across iOS and Android.
• Test on multiple devices to catch performance or layout issues on smaller screens.

3. Leverage Feature Flags

Feature flags allow you to enable or disable features without deploying new code or submitting a new version to app stores.

4. Optimise for Small Batches

Release in small increments to reduce risk and gather feedback quickly. This approach also keeps your codebase manageable and adaptable.

For mobile apps, be mindful that updates can take time to reach users due to app store review delays - leverage Over-The-Air (OTA) updates for updates for JavaScript code and assets in React Native and Expo apps, allowing you to deploy changes instantly without requiring a full app store release. Note that OTA updates are ideal for quick changes such as hot-fixes/bug fixes and small UI tweaks. For larger updates, I always recommend creating a new app store release.

Common Pitfalls to Avoid

Starting a software product is exciting, but here are common mistakes to watch out for:

• Skipping user research: Building something users don't need is the fastest way to fail.
• Overbuilding your MVP: Adding unnecessary features wastes time and money. Keep it simple!
• Ignoring technical debt: Rushing to ship without addressing foundational issues can slow progress later.
• Avoiding feedback: Release early and often to ensure your product aligns with user needs.
• Focusing too much on "polish": Functionality and feedback matter more than perfection in the early stages.

When building mobile apps, some additional common mistakes include:

• Skipping user testing on real devices. Simulators don't account for real-world conditions like slow internet (except in the case of Android emulators) or hardware limitations particularly for low-end Android devices.
• Ignoring platform guidelines. Both iOS and Android have specific design and development standards. Ignoring them can lead to rejection from app stores. I've had iOS app updates rejected by the App Store for simply mentioning Android in release notes.
• Overloading the app with features. Mobile apps thrive on simplicity. Start small and let user feedback guide additional features.
• Neglecting performance. Performance should never be an afterthought. Conduct regular performance reviews and test for regressions with each new feature or significant refactor. Having spent countless hours, days and in some cases months addressing what I like to call performance debt on both native and cross-platform mobile apps, I strongly recommend building with performance in mind from the start.
• Underestimating offline requirements. Mobile users often expect apps to work even without connectivity. Plan for offline mode early if needed.

Recap

Here's a quick checklist for anyone planning to develop software for startups:

Before Building Software:

• Talk to your users and validate assumptions early through user research and simple prototypes.
• Focus on solving real, impactful problems.

What to Build First:

• Start with the smallest feature set that delivers value, and tackle the riskiest parts of your idea.
• Use user feedback to guide your priorities.

How to Build It:

• Use automated tools for testing and delivery.
• Leverage feature flags and incremental updates for faster iteration.

Final Thoughts

Whether you're a founder, developer, or someone with a great idea, building software for startups is as much about learning as it is about doing. By validating assumptions, starting small, and leveraging the right tools and processes, you can create software and mobile apps which delight users while avoiding costly mistakes.

If you have any questions or want to share your experiences, feel free to leave a comment.

Thanks for reading!