The best no code / low code tools and strategies for building your MVP

This is a quick rundown to help you choose the best no code/low code tool to start building your MVP and the best strategy to follow.

To keep it simple we’re just going to call them no code tools. No code tools can be divided into 3 main categories – workflow automation for business/enterprise, website builders, and app builders. We’re going to focus on app builders.

The best no code tools for building apps

After running through hundreds of pages of documentation and community forum posts as well as days worth of tutorials, these are the app builders we would recommend:

None are perfect. They all have their own unique pain points. But they all follow a similar model for structuring an app. If the functionality that your MVP requires can fit within that structure you will have little trouble producing a working prototype in weeks instead of months.

The glaring limitation of no code tools

Here is the main reason why no code tools are best used for building prototypes and MVPs and why you will eventually turn to or integrate custom code as your app matures:

No code tools focus on the lowest common functionality, abbreviated as CRUD.

CRUD stands for “Create, Read, Update, Delete”, which are the four operations you can perform on a database, which is where your app is going to store any data.

How this looks in an app like a marketplace:

• Users CREATE a new item to sell in a marketplace
• Users browse – READ – items available to bid on in a marketplace.
• The current highest bid on an item is UPDATEd when it is made.
• If the seller abandons the auction the item is DELETED.

UX limitations of no code tools

No code tools are further limited in that the interfaces you can build with them tend to be restricted to displaying: 1) static pages, 2) a list of items pulled from a database (like a list of homes for sale in the suburb of Erinsborough), and 3) a detailed view of a single item pulled from a database (like that home on 24 Ramsay Street).

They’re basic standard views. Exactly what you would use in a prototype to make sure you’re pulling the data you expect. While they can be designed and tailored for your app and brand, your UX is still being decided for you.

If you find this too limiting you will need to look towards more advanced no code tools that allow you to also do low coding (or even full coding) like FlutterFlow or Draftbit. But should you code portions of your app from scratch? Do you have the inhouse skills? Can you hire someone who is familiar with your tool of choice?

Obviously, for an MVP, the decision to expand from no code to low code will delay launch and should be considered carefully. Once you start coding your options become unlimited, but so does the time it will take to finish your app unless you have access to the talent to write the code and the discipline to manage your feature list.

The two no code strategies – Build to throw away / Build to keep

If you want to validate your product market fit as quickly as possible, then you can build your MVP using a no code tool with the intention to throw it away and rebuild later from scratch when you have found product market fit.

This gives you the speed of a no code tool. That speed makes it easier to avoid the sunk cost fallacy so you feel okay throwing it away and starting again from scratch using proper tools and a proper framework.

“Throwing it away” isn’t literal. You’ll keep it running while you build the next version.

If you already have users and a market and want to provide an app, then you want to use a tool that allows you to continue to grow your app’s functionality beyond what the drag and drop interface provides. You want to build to keep.

If you want to build to keep make sure you choose a tool that gives you the features you need to implement the complete product you envision. No code tools are simple because they are often limited.

To avoid these limitations you will want to use a no code tool that lets you export the code for your app. See the end of the article to see which tools allow this.

Which no code tool gives you the best chance for success?

Success depends on finishing your app and getting it into the marketplace. Your best chance for success depends on matching the no code tool to your technical expertise. Here is what we would recommend for different levels of programming ability. Choose the one that best describes you:

• Excel power user – Adalo
• Designer who leans tech – Bravo Studio
• Has some understanding of coding -Thunkable
• Writes the occasional script – Draftbit or Flutterflow
• Software developer – Draftbit, Flutterflow or Backendless

Of course there’s nothing stopping you from using a less complicated no code tool. It might give you a speed advantage.

Comparing the no code tools mentioned in this article

Like all options in a crowded marketplace, every choice has its trade offs. This table summarises what we think are the main factors that should guide your decision on choosing a no code tool.

No code may be all the code you need

No code tools continue to add features (like integrating third party APIs) as they compete with each other. What can be built with no code tools today couldn’t be built a year ago.

But don’t let possibility fool you into making your MVP more complex than it needs to be to launch. If you can work within the standard set of CRUD actions combined with list and detail views (which 9X% of apps can) then you will be able to get your MVP to launch with any one of the tools we discuss.

As your experience with no code tools and your understanding of your app grows, you might find it worthwhile to move up to the more powerful no code tools on the next iteration. Combined with a no code backend, you may be able to delay the transition to bespoke code until revenues are high enough to make cutting platform costs worth the investment.

Whatever path you take to build your MVP with no code tools, it’s sure to be shorter than the alternatives.

Freelancers vs team extension – why freelancers always lose

IF you’re an SMB that needs to step up technically, either by building an app, creating a website or even just updating your online presence, this article might save you from freelancer frustration.

As an SMB you’re always at a disadvantage when it comes to tech. You can’t afford to have the expertise you need in house, and hiring freelancers is an exercise in frustration. How are you to stand out in your market, or even compete in it, when tech is now a major factor in success?

We’re going to fill you in on the advantages of a team extension versus hiring freelancers. And you’re going to be glad you’ve learned about it.

What is a team extension?

A team extension is basically remote workers as a service. A team extension can be a single software developer working a few hours a week to a full stack dev team numbering in the dozens.

What differentiates a team extension from outsourcing is that the members of your team extension report directly to you and they are integrated with your in house team, tools and systems. They attend meetings (virtually), they work directly on your projects, and, if they are full time, they work only on your project.

One of the biggest benefits of the team extension is that you have the full support of your team extension service provider. They want you to succeed with their team members as much as you do.

How is hiring for a team extension different from hiring freelancers?

Hiring freelancers requires you to become an expert in IT recruitment. Choosing the wrong freelance software developer can sabotage your plans.

When hiring for a team extension you are hiring out of a proven talent pool with a track record of helping businesses like yours build apps and websites and keep their tech infrastructure running.

With hundreds of completed projects under their belts, your service provider knows the skill set you need and can help you estimate the hours or headcount as well. They are also able to put forward proven candidates for you to interview and pick from.

And unlike with a freelancer, if someone doesn’t work out you don’t lose time or code. You can work with your service provider to rapidly replace them and keep moving forward.

A team extension builds your product, a freelancer sells you code

This is a subtle but important difference. A team extension really is an extension of your team. They’re like employees working out of a different office. They’re output is your output. At all times you have complete visibility into their progress and the work they’ve completed.

Freelance software developers, for good reasons, tend to deny access to any code they’ve written for you until they have been paid in full. There might be online demos they’ve built for you to comment on, but the code remains untouchable.

This gives your project a “bus factor” of 1. Which is how many people need to be hit by a bus to derail your project. Or how many people need to get sick or get sick of the project, to derail it.

With a team extension you have an entire organisation supporting you and your team members. All the code being written is yours and is always accessible. You don’t need to worry about “bus factor”.

Your team extension, and you, get cost and management support

Another major benefit of a team extension is that you get the increase in headcount and productivity without the increase in office space, resources and HR burden.

Your team extension members work out of the service provider’s offices. They supply the workspace and the equipment. They also provide all of the HR and employee support services required. This includes all kinds of work management, training and personal support.

The situation for you is not unlike becoming a team leader where upper management is devoted to helping you get the results you need. You have a second level of oversight to help you successfully negotiate all the challenges of the increased headcount.

What could you build with your dream team?

If you’ve been unable to move forward on the app or website that your business needs because of the challenges in hiring developers, we hope this article has opened some doors for you.

You can build the app or website you need. You can do it while minimising the risks by adopting the team extension model.

If you want to discuss extending your team with some of our talented developers don’t hesitate to get in contact with us.

Building your app with an extended team

 

Building your app with an extended team

Getting Started

1. Briefing with SoftwareSeni about the product you want to build

   We work with you to sketch out the development strategy for your app, web app or website.

2. Decide on a tech stack based on your functional requirement

   

3. Start reviewing developers from our talent pool

   You start with a shortlist of talent that you can be sure have the skills and experience you need. You meet one-on-one for a video interview so you can get to know the candidates.

4. Complete scoping and specification

   Wireframes and business rules are finalised. Feedback during the process ensures balance between budget, features and viability. Full project estimates are in place. You know exactly what needs to be built.

5. Engage and onboard your chosen developers

 

Development begins

Weekly sessions with your SoftwareSeni product consultant and project manager keep the project advancing smoothly.

1. Review product prototypes and give feedback

2. Stay in the loop

   You get daily updates as well as weekly and monthly reconciliation reports so you always know how the project is tracking financially and towards your deadline.

3. Developers integrate your product with the services your business relies on

   This includes payments, CRM, ERP, customer support, reporting, shipping, and more.

4. Infrastructure is configured ahead of launch

   Web servers, database servers, load balancers, CDNs – all the  technical services you need are set up, tested, and placed under monitoring.

5. Final rounds of QA are completed on staging servers

6. Soft launch on production servers with a small cohort of beta users

   Another round of full QA is conducted to ensure there are no incompatibility issues in the live environment.

Launch!

The first version of your product goes live. Your marketing campaign goes into action. You start signing up users.

Post-launch

The first version of your product goes live. Your marketing campaign goes into action. You start signing up users.

• Our Support team keeps your product online

  Need 24/7 uptime? Our team can monitor and respond to any incidents as they occur. Traffic to your product grows and it begins to generate revenue for your business.

What’s next?

• Your extended development team begins to work on the next round of features

OR

• The hard work is done so you scale down your team.

  Your smaller team continues to add features at a pace that matches your budget and incoming revenue.

OR

• Call a product freeze

  Release your extended development team, but retain a part-time developer familiar with your product to handle dependency updates, API changes, service provider issues, etc.

OR

• Expand your customer services team

  Just like your extended development team, use a team extension for customer service to handle the increased enquiries and interest following your successful product launch

How to get your app to market faster

 

The best time to get your app to market is yesterday. Great advice. Not very actionable. More actionable: get your app into the market as fast as you can. If you know you’re already working at your limits, we’ll show you how to get your app to market faster with one phone call. It’s not a secret – a big part of it is an extended development team.

Prioritise the right features of your app to launch sooner

The first step to getting your app to market faster is focusing on the Minimal Viable Product (MVP). The MVP has the smallest set of features that will deliver value to your customers and start generating revenue for your business. 

This means at launch maybe they won’t be able to set a profile picture in the MVP, but they can login, view items and order. That’s what they really want to do with your app. And that’s what you need them to be able to do.

After launch you continue to iterate on your MVP, adding new features and improving existing functionality based on user feedback. Done right, this leads to increasing revenue and uptake of your app, making its ongoing development self-supporting.

Use an extended development team to get your app to market faster

There is a piece of folk wisdom in software engineering that says throwing more programmers at a problem will only make things take longer. This originates in Fred Brooks’ book The Mythical Man Month. Don’t worry about it. It’s true(ish) under certain circumstances. But developing a new app is not one of them. 

As an app can be divided into a front end (the user interface) and a back end (that manages databases, authentication, integration with other services, etc), as well as processes like QA, devOps and provisioning infrastructure, there are multiple focus points where specific expertise, or simply more devs, can move your app forward.

It takes deep pockets and months of interviews to build a team that can hit all these areas at the same time. This is out of reach for most SMBs unless they make use of an extended development team.

The lack of in-house talent results in a long, slow path to launch, often delayed due to missing expertise. Most programmers can learn most programming related skills – languages, frameworks, algorithms, tools – but it takes time and it takes even longer to become an expert. 

So, yes, your React programmer could optimise your database queries, but it would be faster and less error prone to hire a developer who already knows exactly what to do.

This is where the extended team comes in. Also known as a team extension, dedicated team or staff augmentation. An extended development team is a lot like remote workers but with better management, lower risk, and reduced costs.

One of the biggest benefits of an extended team is how quickly they can be put in place and start being productive. If you’re trying to get your app to market fast, this can save you months. This quick set up is made possible by the vendor you will work with.

How do you hire an extended development team?

Hiring an extended team requires a vendor like SoftwareSeni. In SoftwareSeni’s case, we use a hybrid onshore/near-shore model: your consultant is based in Australia, and our talent pool is located in Indonesia’s tech hub, Yogyakarta.

To hire your team you supply us with details on the skills and headcount that you need and SoftwareSeni provides candidates for you to interview. What can take two or three months (including negotiating salaries and paying fees to recruiters) is completed within a couple of weeks. And before you begin interviewing you already know what your costs will be.

How is an extended development team different from a remote team or outsourcing?

In this post-Covid era of Work From Home, an extended team is no different to a remote team. They show up (online). You manage them. They do the assigned work. They attend virtual stand-ups and meetings. Just like the rest of your team. 

However, unlike normal remote employees, they work out of the vendor’s premises. This provides a secondary level of management at no extra cost to you. The vendor wants the developers in your extended team to deliver exactly what you need. They also provide your extended team members with technical and human resource support functions you don’t need to fund or deal with. 

Unlike a typical outsourcing arrangement, you are in complete control and have complete insight into the work your extended development team members are doing for you. 

Move faster and do more with an extended team

An extended team lets you increase your headcount, and development pace, without increasing your budget. The extended team also provides you with a level of flexibility a normal team cannot. 

You can drop team members when their skills are no longer needed. You can add staff to areas that need more attention. All while having complete control over your budget. 

Reduce your time-to-market with a phone call

The first step in getting your app into the market faster is to speak to your vendor. At SoftwareSeni we can help you to quickly finalise team composition and skill sets based on your product goals so you can start building faster. At every step you’ll be in complete control of costs and be able to scale your team up and down to match your budget.

Contact SoftwareSeni to start building your extended team and getting your app to market sooner.

Web app development and your business strategy

 

Smartphones have changed the way people expect to interact with websites on the internet.

55% of internet traffic is from phones and it continues to grow. And 46% of consumers complete the entire purchase process on their phone. This is why we have an article on stats that show why your ecommerce site needs to be mobile-first.

In this article we’re explaining why your mobile-first ecommerce site needs to be a web app.

The App cost dilemma

Apps are eating websites. They’re nicer to use. They’re designed for mobile. They look better on mobile. They have user interaction features that are familiar and designed to make navigation and content consumption intuitive.
This leads to the obvious decision as part of your business strategy to invest in building an app to stay competitive.

But there are a couple of important drawbacks with this strategy.

Your traditional native app is costly to build and maintain. You need to build two of them, one for iOS and one for Android, if you don’t want to lose half your market. And you need to keep your website running for desktop browsers.

Because you need an app you’re suddenly supporting three different platforms and bearing a sudden spike in costs.

Will having an app increase your revenue enough to pay for multiple platforms and still turn a profit?

How long will it take to see a positive ROI if you go down this path?

This spike in costs is why native apps are often out of reach to SMBs and they find themselve losing market share to better funded or simply larger competitors.

Investing in a web app, instead of a native app, is how SMBs can avoid the cost spike and still compete on mobile.

 

Avoiding the high cost of apps

A web app can be thought of as a fancy website, like SpaceX’s Falcon 9 rocket can be thought of as a fancy plane. Technically, they use the same foundation, and even some of the same materials and technology, but the final product, and how it performs, is quite different.

A web app uses advanced frameworks that run in the browser (like React, Svelte, Vue, Angular), to create the same kind of rich interfaces that you find in a native app. There are limitations, because a web app runs inside of the browser on the phone, which impacts performance and access to device features, but unless you want to build a game or access the phone hardware, most businesses don’t need to worry about them.

Because web apps are built with web technologies – meaning they are designed to run within a browser – their single code base can be built to work across all phones, tablets and desktops. Wherever there is a browser they can run. Even on some smart TVs. In practice, a lower threshold is set on the performance requirements, based on your intended market, in order to ensure quality of the user experience.

Using a single web app code base to run across phones, tablets and desktops means web apps don’t create the expensive spike in costs that comes with supporting multiple platforms.

In fact, a web app makes it possible to generate revenue across all platforms, allowing you to observe where you should invest more money and possibly take your web app to the next level.

 

Taking your web app to the next level

One of the most powerful features of web apps is that anyone can purchase from your business on the internet. You don’t have to go through an app store review process or pay 30% to tan app store provider.

Once your web app is live on the internet you will learn a lot. You will learn which platform is your most profitable. You may discover that it will be worth the investment and the fees to turn your web app into a native app.

If you build your web app with the right framework, such as React, you may have already paid for a substantial part of a native app’s development.

You already have the backend paid for and working. All that is left is the interface. With multiple platforms generating revenue, and insights gathered over the months or years your web app has been running, creating a native app might now be feasible.

Tools like React Native can make it cost effective to finally add dedicated support to iOS or Android platforms (depending on your numbers). Using React Native avoids the full re-code to create a native app if, and only if, you built your web app frontend using React.

Web apps for the win online

The internet is the most competitive market in the world. Because it is the entire world online. Pursuing a web app based strategy gives you access to the largest cross section of customers across platforms. Risks are further mitigated by the lower cost in development compared to native apps, the speed with which you can launch new versions without app store approval delays, and greater revenue since you are not paying a 30% share to an app store.

At the same time, launching with a web app gives you a foundation of revenue and feedback that will help you make the move into native apps for your customers if the numbers show it makes sense.

If you want to talk more about how building a custom web app can be part of your business strategy, get in contact with us.

10 SaaS startups that can cut months off your runway

As a LEAN+Agile dev house dedicated to building apps and websites for our clients, we are always advising our clients to buy functionality where they can instead of building it.

We are as aware of their runway as they are. And we’re dedicated to getting them to launch with the best MVP possible. And when speed counts and budgets are limited, and even when they’re not, we always go for buy over build.

Our clients are often surprised by not just the quality but the depth of functionality that is now available to be integrated via APIs from thousands of providers. 

Here’s a list of some of the more useful and powerful integrations you should be considering. Note – this isn’t a survey. We’re not providing options or reviews. Think of it more as a proof of existence and a starting point for doing your own dive into the SaaS options out there. 

 

Feed as a Service – stream

A news feed or activity feed with the rich interactions we’re all accustomed to – likes, tagging friends, etc – drives engagement. Feeds aren’t just for social sites. They’re for marketplaces, ecommerce, any app or website that involves events happening in realtime that someone somewhere wants to see. If you have a database its contents can probably be presented as an infinite scrolling feed to your users to like and share.

All that rich interactivity is complex and time-consuming to implement. Then there’s the technical difficulties involved in delivering the feed to all your users so they have a smooth, hiccup-free experience. You’re looking at 1000s of programmer hours whether you sit down and do it right and eat the delay, or launch with the basics working and iterate towards the complete solution.

stream provides APIs for client and server feed management as well SDKs for building apps and websites that integrate their feeds.

 

Authentication as a Service – Auth0

How many ways are there for potential customers to login and access your product? Email address + password? Social logins? Magic email link? SMS link? Let them use it anonymously and authenticate later? Multi-factor authentication using a code sent via SMS, voice, a one-time password app, a hardware key or biometrics? 

It depends, doesn’t it. But security is one of the hardest things to get right. A home-rolled solution will be enough for the early stages of development, but once you’re live on the internet your vulnerability is related to how much money, time and expertise you can spend on security.

Or you can use a provider such as Auth0 who is solely focused on secure authentication.  

 

Fraud Detection as a Service – Sift Science

As the pandemic created a surge in internet usage and online purchases, it also created a surge in digital fraud across both true fraud and friendly fraud categories. If you haven’t heard of friendly fraud, it mainly manifests as chargeback fraud – customers claiming they never received their order. 

Digital fraud requires cooperation and huge datasets to detect and defeat. It’s not something you can do on your own. Services like Stripe Payments and Sift Science integrate thousands of data feeds and signals – such as device fingerprints, transaction histories – to predict and mitigate fraud.

Should you be using their services? If you’re not sure, your accountant can probably tell you.  

 

Images as a service – imgix

Images have a huge impact on your users’ perception of your app or site. They can make it look more engaging, but due to their size loading them can also slow it down. If you rely on user-generated content, like a restaurant recommendation app would, or a marketplace, or you have your own deep catalogue of product images, then handling images and handling them well is an absolute necessity.

But manipulating images is technically challenging and delivering them quickly to your users takes planning and infrastructure.

Services like imgix save you from having to develop inhouse image editing and management expertise. It provides an API that can crop, resize and compress images, and a CDN for caching and delivering them to your users. 

You might say there are open source libraries for manipulating images and Amazon has a CDN, so why? You can ask the same question for every service in this article. The answer is time. Time now, as you move towards launch as quickly as you can, and time later, when you lose feature development hours to maintaining and debugging the code you wrote in house.  

 

Recommendations as a service – Algolia

You have an online store. It would be nice to increase Average Order Value by surfacing appropriate products for your customers. Where do you even start on that? Do your developers need to know statistics? Machine learning? Can you afford developers that already have the skills?

Even with a feature that will deliver a positive ROI it may end up being too expensive, again in time as well as money, to implement or just impossible. A lot of the modern user experience is pretty close to rocket science. But not everyone can hire rocket scientists.

But a service like Algolia lets you access that rocket science through an API that is easily integrated and with pricing that is easy to sign off on.

 

User Comms as a Service – twilio

There are dozens of services that will help you put a chatbox on your site or in your app. Making it easy for a customer to talk to a rep to help boost conversions is a strategy that is growing in popularity as it gets easier to implement.

A text chat today might lead later to a call to support after purchase or an email with warranty information or a newsletter with your latest offers.

We’re highlighting twilio for this category because their service offers APIs that allow you to integrate chat, voice and email comms with your customers. On top of the comms, it allows you to unify all your interactions with each customer to streamline engagement and allow you to personalise their interactions with your business.

This is the kind of feature you don’t even dream of being able to build for yourself. You use theirs and you’re grateful you can leverage it to your advantage.     

 

Payments as a Service

This is a no-brainer. There is no question you are going to use a third party payments API. You’re trying to launch here, not reinvent online banking. The question you have to answer is which one, or which ones, are you going to integrate?

And are you going to stick to straight payments through a service like Stripe or are you going to integrate a Buy Now Pay Later service like Afterpay or Klarna? 

 

Onboarding as a Service – Pendo

For an app or site of any complexity one of the biggest challenges is onboarding new users so they can use your powerful features, recognise the value of your product, and become long term customers.

This onboarding is handled by tours using on-screen pop-ups and overlays. The value is in the tour, not in the code that animates the tour.  

The advantage of integrating a service like Pendo is that their implementation of product tours has advanced to the point where it offers authoring tools. This frees your developers from having to dedicate time to what is intrinsically a marketing function. 

Pendo also collects data so you can see which features are being used, allowing you to continuously improve your onboarding experience and profit from it.

 

Shipping as a Service – ShipEngine

If your business deals in physical items then you’re going to be dealing with the headaches of shipping. It’s a time sink that cuts into the profits of every transaction.

Services like ShipEngine let you use a single integration to hook into a network of delivery and logistics companies, allowing you to optimise your costs and helping quickly and painlessly arrange local, national or international deliveries.

Security as a Service – Wazuh

Your business is online. You have a server. Perhaps multiple servers. They’re all connected to that hive of scum and villainy that is the modern internet. What are you doing to keep your business secure? How much time and how many developers and devops can you dedicate to security? 

Staying current with threats and mitigations is a full-time job for a team. Being able to lean on the smarts of a large, dedicated security team through services like Wazuh reduces the risk of you being knocked offline or worse. 

Are you going to buy or build?

Software is a different kind of business. And if you have a website or an app make no mistake, you are in the software business. Pick almost any portion of an app or service and a deep expertise is either necessary or provides a huge advantage. 

This is what makes SaaS such a pervasive model. It’s the expense of expertise distributed across hundreds of customers. This business model is creating the re-usable modularity of functionality that software businesses have been wishing for since the 80s.

Any app can now launch with top-tier features in a fraction of the time and the fraction of the budget that was possible just five years ago.

You might worry about lock-in, and seeing money going out the door to other services might cause you physical pain, but that’s a problem that can be solved down the road when you are big enough for it to matter. 

For launching a new website or app, a strategic set of SaaS services can get you impressing customers and pulling in revenue faster than you can imagine, no matter how many developers you have.

If you want to talk to us about your own buy vs build challenges or you’re looking for extended team members to help you build, get in contact with us. We’d be happy to discuss the options open to you.

The big $$$ questions about app development answered

We see the same questions about app development coming up again and again. It’s no surprise. More and more businesses are recognising that they need apps. Developing apps is a complex and opaque process. They’re big ticket items where unscrupulous operators don’t want to share numbers until they can guess how much you have to spend.

We’re going to fix that. By answering your questions. Many of them are of the “how long is a piece of string” variety. We can’t tell you how long a piece of string is, but in our answers we do give some recommendations on how you should be thinking about your string. Or, for this article, how to think about your app and how you’re going to get it built.

Q: How much does app development cost?

Short answer: Under $50,000 for a simple app. Under $150,000 for a basic app. Over $150,000 for a complex app.

Long answer:

You need to be comfortable with spending 5 and 6 figure sums if you want to build a competitive app. If you don’t think you’re going to earn the money back then now might not be the right time to start the process. Maybe start with a basic website.

The cost at each tier comes down to complexity. That complexity is a combination of frontend features, backend/admin features, third party integrations, the amount of business logic that needs to be encoded (after being documented!), and the variety and volume of traffic and transactions your app needs to handle.

A short discussion with us about your app, your market, and the features you want would enable us to tell you which range your app would fall into.

Q: Why does app development cost so much?

Short answer: Details x Time x Expertise

Long answer:

We understand this question. Unless you have worked as a developer on multiple similar projects it can be impossible to look at the screens of an app and see where 5 and 6 figure sums were spent. Hint: a lot doesn’t show up in the user interface.

App development costs what it does for two main reasons: it requires expertise and it takes time. And then there are the details. Building software is all about managing a mind-boggling number of details. It is not unlike building an actual sized house out of Lego bricks. Individually positioning all those little pieces adds up to a lot of time. And you need people who know how all the pieces fit together.

When looking at the cost it helps to remember app development is an investment. You invest in an app to generate revenue. Much as you might buy a machine for a factory, or pay to rent, fit-out and stock a brick and mortar retail store. You expect your big investment to give you more in return.

Of course you’re cost conscious. You spend your money wisely. That is why SoftwareSeni provides full transparency during the entire app development process. You can see the time spent at each stage of app development and even for each feature. Also for all the code that doesn’t touch the screen – the integrations with other services, the code that talks to the database, the code that creates the backend that your business will use.

Q: How long does app development take?

Short answer: At least a couple of months to launch. Then months to polish. Then years to grow.

Long answer:

Our business philosophy combines Lean and Agile methodologies. Under Lean, businesses want to be launching an MVP (Minimal Viable Product) as soon as possible to verify their idea, start gaining users, and start generating revenue.

This is done by implementing features in two-week work blocks called sprints under Agile. You won’t be launching your MVP app after 1 sprint, but 4 isn’t impossible, and 6 is feasible. All depending on your feature set and how far advanced your product conception is, of course.

And once launched, new features continue to be added using two-week sprints, along with addressing any user feedback received along the way.

This process results in lower upfront costs, puts a working Android app or iOS app, or both, in front of your customers sooner, and enables you to start generating revenue sooner.

Q: How big a team do you need for app development?

Short answer: 3-5 depending on the stage of development.

Long answer:

The app stores are filled with apps built by a single developer. So is that all you need?

Maybe? But there is only so much a single developer can do in a week. Or a month. There are only so many facets of app development a single developer can be an expert at. And how many developers are also experts at graphic design or UX or at running user testing?

And the big issue with a single developer – it only takes a single accident, or a single personal crisis, for your app development or app support to grind to a halt. What business wants to take on that risk profile?

A serious app, with a sensible launch schedule, that looks good, that works well and continues to work, requires a team. The size of that team depends on the app, its features, and how the development can be scheduled. But we find that, on average, at any particular stage of the app development process, you need about 3-5 people contributing.

It is a truism of software development that the best way to slow down a project is to throw more people at it. At SoftwareSeni we have launched enough apps, and our teams have collaborated on enough of these apps, that we’re pretty good at putting together the optimal team for creating your app.

Q: Should I develop an app?

Short answer: If you have to ask then you should develop a website first.

Long answer:

An app is a major investment. Are you sure you’re going to get a return on that investment? If you’re not sure, if you don’t have a ready market or an eager customer base, then it will be wiser to test your business idea using a website first.

A modern website, designed to be mobile-first, can approach the user experience of a dedicated native app with a lower upfront investment while providing you access to the entire global marketplace across all devices, not just phones.

Q: Should I develop an Android app or an iPhone/iOS app?

Short answer: Android if you want market reach, iPhone/iOS if you want to charge a premium.

Long answer:

In most of the world Android is the dominant mobile operating system, holding about 75% of the global market. But in some markets, like the US, UK, Canada and Australia, iOS holds more than half of the market.

This difference in market share, and user base, leads to a non-intuitive result. Global non-game app revenue in 2020 was $32.1 billion. Despite its smaller global market share, at about 25%, iOS apps captured $24.7 billion, or 77%, of that revenue.

The decision to develop an Android app or an iPhone app comes down to knowing where your audience is and what your goal is.

For markets like Australia, USA, UK and Canada, where the market is almost evenly split, it’s lucky that there are frameworks like React Native that make developing apps for both platforms financially feasible. But still we would recommend focusing on your iOS app first, because that platform will likely provide most of your revenues.

Q: How long does it take for an app to earn back its development cost? Also: How long does it take for an app to cover its running costs?

Short answer: If you read the first question you already know the answer.

Long answer:

This question is looking at app development backwards. You should not be spending money on developing an app, or purchasing any asset, without forecasting or modeling costs and revenue.

The real question should be: given my forecast revenue and current budget, can I build an app with the planned feature set, keep it running, and market it?

(You don’t want to forget your marketing budget. Expecting enough people to simply stumble across your app is not a path to success.)

If the answer to the real question is no, you don’t have enough money to do all that, then you are left with three options:

1. Don’t develop an app. Put your money towards another revenue generating project.
2. Reduce the scope of your app. Will a simpler, less expensive app bring in enough revenue to fund further development?
3. Build a website instead.  A Web app or a dedicated ecommerce website development is a faster way to reach an even larger market. Websites can have app-quality interaction (at a price). This approach can allow you to invest even less up front and still have a foundation you can extend as revenue grows. With proper planning, converting it to an app when revenue allows can be quite cost effective.

Still have questions about that app you want developed?

Hopefully by answering the big questions about app development we’ve helped you think strategically about getting your app developed.

If you find you have more detailed questions on costs and starting app development then get in contact with us. We’re always up for a chat and we love finding revenue-focused solutions to app creation.

Now, if you feel like you want a little more background on app development before talking to us, we have written a series of short, easy-to-read articles on the process:

A quick guide to Agile for businesses and start-ups
What is product conception and how to do it
How to prototype your app
Business rules and the business logic that drives your app
How the app development process works

Also, here are two articles that will help with your decision making:

Should you build an app or a website?
Fixed price contract vs Agile for app development

Contact us here for any questions you still need answered.

Should you build an app or a website?

The title might strike you as a dumb question. App vs website? We’re deep in the 2020s. You probably already have a website. But if you’re launching a new product or service or ecommerce play, or you’re finding competition is eating into your revenue, then the question is one you’re already asking yourself – go down the path of, say, ecommerce app development, or down the path of ecommerce website development? 

This article is going to help you make that decision. It’s going to start with a quick tech review, followed by a short discussion of the trade-offs between the two options, then it will jump into the surprise “have your cake and eat it too” twist.  

Let’s start with the tech.

There are only three types of websites

That’s right. Only 3. We’re talking under the hood, not content. Here they are:

Static

Static websites serve visitors pre-generated pages of content. This is how websites worked when the internet was born. It’s had a resurgence in popularity recently due to its speed and security. This tech is best used for sites that don’t change often – blogs, documentation, and brochureware sites.

Dynamic

Dynamic websites serve visitors pages that include content pulled from a database or generated by code. This is called server-side rendering, as the layout and content is assembled by the server delivering the page. It’s more complicated than that, but we’re keeping things simple. 

If a website isn’t static then it’s dynamic. This includes the millions of WordPress sites in existence along with every other site on the internet. The term “dynamic” is now more of an umbrella term, as there are many different ways to build a dynamic website. Web apps represent a relatively recent strategy for building dynamic websites.

Web App

You might have seen this style referred to by a couple of acronyms: “SPA” / “PWA”. “Web app” is simpler. and they all mean a website built to behave like an application. Instead of responding to user interaction by following clicked links to new pages rendered by a web server, web apps pull data off the server and redraw the contents of the current page to display it. This is faster than requesting and loading new pages and creates that “app” feel.

The biggest difference between a web app and web site is web apps are more complex than server-side dynamic websites due to the added complexities of marshalling content on and off the page and the richer interactions they tend to implement.

Twitter is an example of a web app that features the kind of detailed interface and high level of interactivity that used to be only associated with dedicated apps.

If a website looks like an app and acts like an app, is it an app?

No. While you can build a website with an app-level user experience, when it is visited from a handset it will not have the integrations into the handset operating system a native app will enjoy. It will also lack the look and feel of a native app, placing it visually in a lower tier.

Performance in some areas will also suffer. The biggest one is smooth scrolling. Despite the power of modern handsets, the complexities of displaying rich content in a browser window is still not as smooth and efficient as within a native app. 

Is it easier to build an app or a website?

A modern website built from scratch instead of on top of an existing platform like WordPress or Ghost can be as complicated as an app. When you have things like user authentication, a database for storing data, a way to send emails, an admin interface for tracking metrics and providing customer service features, as well as a professional user interface, you are looking at a lot of code just as you would with an app. With features comes code. There is no avoiding it.

However, there are some tools out there that will make an app from a website. Really, it is just a an app that only displays your website. But users can already access your website on their phone, as we discuss below, so why go this route?

Keeping the killer feature of websites

Websites have one killer feature that apps don’t have – they run everywhere. They run on desktops. They run on phones, no matter who makes them. They can even run on smart TVs. 

When you are deciding between an app and a website you need to understand where your users are and how they are going to interact with you.

It’s a balancing act between audience, features that you need, features that will appeal to the audience, and cost. 

The cost of websites vs apps

A native app with similar functionality to a website is going to cost more than the website. The main reason is simple economics. The number of app developers is much, much smaller than the number of website developers and demand for their services remains strong.

As each of the two major platforms, Android and iOS, have different development environments, releasing your app on both platforms can (roughly) double your costs.

Another cost apps must pay is time. Getting approval for your app from each platform app store takes time, sometimes weeks, with any problems potentially causing long delays. No-one can stop you from launching a website whenever you want.

Each option has its benefits. But you should know there is a strategy that can get you the best of both worlds – the lower cost and lower time to market of a website, and the power and polish of a native app – while spreading out your risk.

The app that starts out as a website

This is our favourite strategy for creating a new product or service. It combines the rapid development and deployment of a website, while at the same time it lays the groundwork for the heavy lifting required to create an app.

This strategy is based on React Native. React Native is a spin-off of ReactJS, one of the world’s most popular JavaScript frameworks. If you’ve never heard about React Native you might want to read Everything you need to know about React Native apps – the business side. 

By building a web app using ReactJS it takes much less effort to convert it to a native app using React Native. 

By starting with a web app you can prove the business model of your product or service with a lower investment than going straight to a native app. Once the business model is proven, moving from web app to native app is straightforward. 

How straightforward depends on including this path in your strategy. And why wouldn’t you? Your app will use the same backend as your website. Your UX has been tested and proven. If you built your web app on ReactJS it becomes a matter of changing code that would tell a web browser to draw a form to React Native code that displays a native form on a handset.

And the same React Native code works on Android and iOS. You don’t need a separate team for each platform.

The final answer to the app or website question

So, the final answer to whether you should build an app or a website is you should build the website first. A website designed to be a web app. And if you use ReactJS that website will take you 80-90% of the way towards your app.

When the website shows you have a foothold in the market, it is simply a matter of converting the website into a native app.

If you want to know more about this strategy and how it could work with your business, get in contact with us and we can discuss the details with you.

Making it real – the software development process behind your app

This article is going to go into details on the software development process at SoftwareSeni. The target audience is our clients and potential clients. If you’re thinking about getting an app or a site built some day, then you will find it interesting to understand how these processes are run.

The article is a follow on from similar articles on product conception, prototyping, and business rules. 

With all the above completed, the software development can now start. If you’re curious about the cost of software development, we recommend reading our article on Fixed Price Contract vs Agile Development. 

SoftwareSeni is an Agile house. Software development under Agile has a definite beginning, but it doesn’t really have a middle or an end. This is due to the iterative nature of Agile development. One of the early iterations will see the launch of your product. But once it is live each iteration after that will be launching new features and capabilities. 

The beginning of the software development process

At SoftwareSeni we divide the beginning into two phases: Preparation and Kick-off.

In the Preparation phase we take the wireframes and business rules and use them to create the product backlog.

The product backlog is an Agile thing. It is the single source for everything that the dev team needs to work on. So it includes the features of your app that need to be implemented, but it will also contain bug fixes, setting up hosting infrastructure and any changes it needs — anything and everything the dev team needs to complete your app and keep it running.

Using the product backlog, work is prioritised based on impact and effort. The business rules you documented earlier are broken down into epics. The epics are broken down into stories and those are finally broken down into tasks. All of these go into the product backlog.

Because the product backlog is used to prioritise work it is not a static list. Everything that needs to be done gets added to the backlog as it pops up. This requires the product backlog to be regularly updated and re-prioritised. This is part of the Agile process.

Along with the product backlog, the preparation phase involves:

• a sprint plan
• the confirmed timeline and milestones
• a demo plan (both internal and for you)
• establishing development environments (typically separate Dev, Staging and Production systems)
• a QA Strategy and Plan that covers automation, test plans, test scripts, test data, and resource planning.
• a User Acceptance Testing (UAT) plan covering the application security checklist and penetration testing

Kick-off

The kick-off for your project is carried out in two meetings. For you, it’s a briefing where we communicate how the software development will proceed and we all confirm we are in agreement on project goals, deliverables and timelines.

The team runs through the same information in their own meeting. This is also the point where the final structure of the team — headcount and skillset — is settled.

After this, the development begins.

The Agile development of your product

Agile operates as a series of sprints. Don’t imagine a roomful of people pounding at keyboards. Programming is a slow and thoughtful process. Agile packages that process into short, often two week long, periods of focus: the sprint.

If you’re new to Agile you might want to read Agile basics for small businesses and start-ups.

The first series of sprints are focused on getting your MVP in front of customers. Once your app or site is live subsequent iterations make it easy to adapt focus and schedules based on app usage and revealed needs. 

A sprint is divided up into multiple stages that can be summarised as: 

• planning what to work on
• doing the work
• reviewing the work

The result is a two-weekly cycle that runs like this:

Keeping you in the loop

The beauty of Agile is the regular feedback on progress that is available. You will have opportunities to review work to date and current progress at multiple stages through the project. This will be via weekly or fortnightly Work In Progress (WIP) meetings. This is on top of the weekly reports and updates that we send you.

These meetings are essential to ensure your vision of the app is being correctly interpreted by the team. This might sound surprising, but every product is the sum of thousands of tiny decisions. Being involved in the process, supplying clear and concise feedback, ensures your vision is fulfilled as efficiently as possible.

Development never runs issue-free. There are always issues related to usability or functionality that could not be foreseen from wireframes and business rules alone. These are the kinds of things that more documentation can’t fix. They can only be discovered during the building and testing. 

But this is exactly what the Agile process is designed to cope with. Any issues revealed get added to the product backlog and prioritised and the project keeps moving forward.

Sometimes these issues will impact product scope or your preferred timeline. Agile lets us catch these early and our regular reporting to you ensures you have time to act quickly on them.

Demo day

As you know, software development is often divided between front end — the UI and UX your customers will interact with, and back end — all the code that interfaces with your business, talks to databases, handles logins, etc. 

Once the sprints covering both facets of your app reach a mature enough state fortnightly demos begin. These are yet another opportunity to keep development aligned with your vision, to spot any issues and to just enjoy seeing your product coming to life. It’s an exciting part of the process.

Rushing towards launch

Once the demo days start you are closing in on the launch of your MVP. While you are preparing your marketing push for the big day, the SoftwareSeni team is running QA on your app, hunting down and squashing bugs. They are also preparing for the User Acceptance Testing (UAT) to ensure that your app, and your users, will be secure. 

The first launch is just the beginning. It’s definitely memorable, but you will be launching a new version with new features and new fixes every two weeks as your user base grows and your product’s functionality grows with them. This process will become part of your business’s day-to-day workflow.

The new normal

The Silicon Valley phrase is “Software is eating the world”. Once your product is live, whatever your business is, it is now in part a software business. And as long as you’re in business, SoftwareSeni will be there to help you with insight, strategy, tech talent, and raw people power.

If you’re ready to transform your business into a software business with an app or website, get in contact and let’s get the process started.

If you’re new to the process, we recommend starting with our article on product conception – bringing your business idea to life.

After the wireframes – the rules at the heart of your app

If you have been reading our series of articles on the app development process, this is where the hard work begins.

If you’ve stumbled upon this article, it follows on from our previous article on prototyping your app. You might want to start on the first article in this series: Product Conception – Bringing your business idea to life.

At this point in the process your wireframes are a beautiful representation of how your app will look. Your clickable prototype is an accurate representation of how some of the features will work. Together they give you a real feel of how it will be to use your app. User-testing with this early stage prototype has shown the people get it and want it.

App development has been fun so far. Your vision has taken form. The process has been visual, iterative and the challenges have been a joy to solve.

Now it’s time for the hard work. If we knew what you were wearing we’d tell you this is the point where you start rolling up your shirt sleeves. Maybe make the first of many strong cups of coffee.

The hard work is producing the business rules for your app. Business rules will be the core of the technical specifications for your app.

Business rules – the core of your app

The business rules detail exactly how each button, each slider, each interface element will work. It will detail how actions taken by your users through your app’s interface will interact with your business processes, third party services, and your backend.

It’s all about the details, details, details, and thinking them through and getting them right. This is why it is hard work. And why it’s important work. Getting your business rules right the first time saves you money and time.

As the core of your app’s technical specification, they will enable the developers to work out the infrastructure you will need to run your app. Things like:

• where your backend will live
• how the backend is structured for scaling and redundancy
• what services you need to run yourself
• what third party services you will contract with

If your business already has technical infrastructure the effort will instead be spent on how to integrate it with your existing set-up.

But those big decisions are things we work on with you. We’re here to give you the benefit of our experience across hundreds of client jobs during every step of the process, including advice on writing the business rules.

What business rules look like

There is no standard format for business rules. Some clients have presented us with complete technical specification documents. Others have used a spreadsheet to list out how they want their app to function. A popular option is laying out the screens created during the wireframe stage alongside the details of how the interface elements on the screens will work. That’s what we’re going to do here.

For this example we are going to pretend that we are building a mobile app for dining recommendations. Let’s call our imaginary app Bancwit. That name needs a few more iterations, but it will work fine for us.

We’re going to specify the business rules for the main screen of Bancwit. This screen is where they start the selection process for a dining destination. It provides access to all the venues registered with Bancwit as well as directing users to venues in their immediate vicinity.

Some of the functionality is obvious, but as you can see below there is some business logic that can’t be derived from looking at the prototype. This can all be done within Google Docs for easy collaboration. Below we use a simple two column table with the screen on the left and the relevant business rules on the right. It helps to work from the top down.

What business rules aren’t

Business rules are purely about what needs to happen, not how it will happen. The how will be handled by the developers once your business rules are complete. That process will be covered in a future article.

Business rules are not flexible. And they are not vague. The business rules need to be simple and clear enough that a developer can code them without the need to hit you with questions. This is another opportunity to save you time and money. Meeting this level of clarity takes practice. We’ve had the practice and it’s one of the many things SoftwareSeni can assist you with on the path to launching your app.

Let the programming commence

That’s it for this short introduction to business rules. Unless your app has some particularly tricky tech that needs implementing and testing, completing the business rules brings the prototyping phase of your app’s development to an end.

The next step in the process is software development. We will cover how SoftwareSeni handles building your app, and your role in the process, in a future article. Until then, if you have an app or a web site of your own that needs work, or if one of our extended teams will help you hit your goals, get in contact.