How a team extension can help your business achieve everything you want

SoftwareSeni’s team extension services help our clients do the impossible: shorten runways, add features outside their capabilities, access talent outside their budget, and achieve more with the resources they have to hand. 

This article is going to introduce you to the team extension model (aka extended team model), show you how other businesses are using these teams, and get you thinking about what you could accomplish with a software team extension and how it could transform your business.

Team extension in a nutshell

An IT team extension or developer team extension is a specialised form of staff augmentation. Rather than a patchwork fulfilment of roles within a business, a team extension’s purpose is to strategically target the skills and experience you need and integrate them cleanly and effectively into your development process.

The extended team works just like the original team. They report to the same people, they share the same goals, use the same tools, and work on the same codebase as your existing team. 

Isn’t this just out-sourcing? And doesn’t that have drawbacks?

You might argue that team extension is just out-sourcing. The members of your team extension are out-side the office. But with out-sourcing you are handing over the entire production of a product, along with any control you might have, to a third party. 

With a software team extension you maintain complete control. Your extended team participates in stand-ups, meetings, and planning alongside your existing developers. And unlike out-sourcing, they are dedicated solely to your project. You, or your project or product manager, decides where their time is spent, just like your in house team members. 

This does require that you have the ability to manage the higher headcount and the complexities that might bring to scheduling, communications and prioritisation.

So an IT team extension is about getting cheap programmers?

No. It is about accessing talent. Team extension often makes use of programmers in off-shore and near-shore markets. Depending on your local market and the competition for talent, they may be the only way to access the skill sets and experience you need. 

The SoftwareSeni talent base is near-shore, based in Yogyakarta, Indonesia, a national tech hub. This provides a great time zone overlap, unlike other locations. And our talent base are all developers we’ve worked with across multiple projects. Some have been with us for years. 

Having access to a pool of proven developers is an incredible advantage. The biggest advantage you should care about is time. Speed of execution. There are multiple financial advantages, which we will outline later, but the time advantage is where we think the extended team model pays dividends.

The time advantage of a software team extension

When you think about adding to your head count you automatically think about how much faster work will be completed and how much more quickly goals will be reached. Mostly true, though the Mythical Man Month would say temper that vision with a grain of salt. But there are even more important ways a team extension gives you time advantage.

Reduced time to productivity

Time to hire can be months, particularly for in-demand skills. Between waiting for viable candidates to apply, interviews, negotiations, resignation periods, and onboarding, you can lose a big chunk of a year making a single hire. And if you’re building a team with interlocking skills the time before the team is operating at the level you need can be even longer. 

Extending your team through SoftwareSeni reduces the interview process to assessing team and organisational fit. You choose the pre-vetted candidates you want to talk to. That’s it.

Less time to integrate them

After finding a developer someone on your team needs to make space for them, find them a desk, purchase and prep a computer, get their details into all the HR and payroll systems. 

You don’t need to do any of that. We provide all of our programmers with the space and equipment they need to be productive from day one. All the administration is handled by us as well. For you, they are there to help you meet your goals from day one.

Shorter time-to-feature

At this point – team selection complete, new developers onboarded and ready to go – you’re already a couple of months ahead. With professional project management, your extended team will be completing more sprints, increasing the feature count delivered each cycle. Or you will be moving forward on the direction that had been walled off to you because you didn’t have or couldn’t afford the resources.

The cost advantages of a team extension

The upfront cost advantages of a team extension were implied in the section above. We’re not recruiters. We don’t charge fees for placing our programmers in your team. That will save you five figures per team member. 

Ongoing costs are set. You know how much you are paying for each extended team member. It’s a predictable number you can budget around.

Costs like office space, equipment and the like are zero. They are taken care of by SoftwareSeni. 

Despite all this, we don’t think you should be thinking about your extended team in terms of costs, but instead in terms of earning potential. Focus on what you can achieve with a team extension and how that will impact your bottom line.

The challenges of adopting a team extension

Any rapid increase in headcount can be a management challenge. This challenge is magnified by the remote nature of the extended team and the communication hiccups that can result from a multinational team.

You will need to ensure you have project management capacity in place to handle the increased head count. For some businesses, this is the greatest risk to an extended team and the most common cause of reality not meeting expectations. 

Finally, for a close-knit team it can take time to adjust to and integrate multiple new team members. 

All these challenges can be overcome. We’ve seen it happen. We’ve helped it happen. That is another benefit of a SoftwareSeni extended team – you’re not in it alone. Hire an employee and their problems are your problems. Extending your team through SoftwareSeni and we are there to support you and your extended team through the challenges and onto success.

You’re never too big or too small for a team extension

We obviously can’t go into details, but we think these brief examples will help you get an idea of how an extended team can be structured and what you can achieve with one.

Site production and support

A major media organisation uses an extended team of 3 part-time developers on a dedicated sub-site. The developers are split between implementing new features and devops.

Accelerator team

A startup in the energy marketplace increased their development capacity by 30%. Eight SoftwareSeni developers are currently helping them fast-track features.

Entire tech team

A two-person startup in the real estate market with a great idea and no technical skills built their entire product using a dedicated software team extension from SoftwareSeni. That team continues to add features and keep the business running smoothly.

Full operation support

Another real estate services business runs their entire business with an extended team from SoftwareSeni. 75% of the team is software development and technical support. 25% of the team provides customer support. They keep thousands of paying customers happy.

What could you achieve with a team extension?

At this point we hope your brain is ticking over with the possibilities. You have some solid insight into the advantages and disadvantages of pursuing a team extension. You can see the unlimited upside.

The next step is to talk to us. We can help you turn those possibilities into a plan and make that plan a reality.

Contact us here. We provide extended development team services and staff augmentation.

If you’re thinking you might not be able to handle an extended team, check out our article on the simple secrets to making an extended team work.

Product Conception – Bringing your business idea to life with the Lean Canvas

In this article we’re going to talk about product conception. We’re going to start with a broad overview of what a viable product idea needs. Then we’ll cover the process — the steps you need to take, the information you need to uncover — to complete your product conception. We’ll use the Lean Canvas for this. The Lean Canvas is a top level summary of your idea that will serve as your blueprint as you move onto the next stage, prototyping.

Why are we qualified to talk about product conception? Experience. Since SoftwareSeni started in 2013 we have taken dozens of businesses from initial idea to launch. We know the blindspots. We know your market isn’t “everyone”. We know how to dig to the core of your idea.

That digging is what this article is about.

The difference between a Good Idea and a Bad Idea

The best ideas come from insiders. People with years of experience and a detailed knowledge of a particular market. Maybe that’s you. Perhaps you’ve seen a pain point being ignored, a gap in the market, or an even larger, more radical opportunity.

This recognition of a real world problem that is calling out to be solved is the first sign you are onto a good idea. Bad ideas tend to be solutions to problems no-one has or no-one is willing to pay to fix.

Good ideas often arrive along with a vision for how to solve the problem. This vision is the start of the product conception.

As a vision, the solution is exciting, inspiring and rich with promise. It’s all three that drive businesses forward. But at this early stage, before vision has met reality, you already need to be prepared for it to grow and change.

It’s not the best quote, but “No plan survives contact with the enemy” is the most relevant. We can paraphrase it as “No business idea survives contact with the market”. At SoftwareSeni, we find it’s the teams that can adapt as they learn more about the intersection of their idea with the market that finish with the best results.

How to explore that intersection between your idea and the potential market, what you need to do and learn, can be a mystery if you’ve never attempted it before. Luckily, there’s a framework that provides a clear guide — the Lean Canvas.

Uncovering your blindspots with the Lean Canvas

Filling out a Lean Canvas will help direct your research and your thinking. It’s not the only way to conceptualise a product, but it’s easy to implement and it’s effective.

The outcome of completing the Lean Canvas is a clear understanding of your product and the business you are going to build around it. It is the necessary input and foundation for your prototype.

Let’s run through the sections of the Lean Canvas.

Lean Canvas

Problems and Solutions

Problems are the pain points you’ve recognised. If you’re diligent you’ve already confirmed they are actual pain points your potential customers have and are willing to pay to fix.

You might be thinking there’s not much space to write these things down. That’s the plan. You want to be concise and clear. It is a communication tool as much as it is a planning tool.

Key metrics and Unique Value Proposition

How are you going to measure progress and success? If you’re a start-up or a scale-up you might be focused on growth and interested in your DAU/MAU ratio or your churn rate. Perhaps you’re also focused on optimising your funnel and you want to track your Cart Conversion ratio. Write them all down.

Your Unique Value Proposition (UVP) is why people should choose you over the market incumbents. Is your UVP viable? Is it valuable? To your users? Is it compelling? Is it new? (Is it just another way to say Unique Selling Proposition?)

High Level Concept

This is the classic “Uber for X” statement. A single, short sentence that communicates what your product is about. Is it Facebook for pets? A concierge for cosmetic surgery? Craigslist for Gamers? AirBnb for medical tourists? A marketplace for pig breeders?

You want a statement here of such clarity that whoever hears it will grasp immediately  how your product will work and who will use it.

Unfair advantage

This is a factor that your competitors will find difficult or impossible to replicate. It could be that you’re first in the market. Or your team has cornered the expertise needed. Maybe it’s personal — you’ve built up a community that is eager for your product. Perhaps you have a gun team that can out-manoeuvre the competition.

The bottom line is you want something to protect you from the competition. Once your app goes public and your success becomes apparent competitors will rush in.

Channels, customer segments and early adopters

You need to know where and how you’re going to reach your users. You need to know who they are and what their story is. Key amongst your customers are the early adopters. These could be the users who are simply more inquisitive, more adventurous, or the users who are desperate for a product that will solve their problems. Knowing who they are is the first step to working out how to reach them.

Cost structure and Revenue Streams

The outs and ins of your business model. The cost structure here is of course your initial cost structure. In the beginning it can be the right thing to use strategies that don’t scale. Throwing money at street teams when you launch might be the most effective growth accelerator for you.

The Revenue Stream box is where you lay out how your product is going to earn its money. It could be sales, subscriptions, transaction fees, etc. Don’t have a revenue stream? Congratulations, if you can keep growing fast enough after you go live you might be declared a unicorn, pivot a few times, and back into an IPO via a SPAC before starting your own angel investment firm.

On a serious note, these two boxes will feed back into your Key Metrics. Make sure the relationship between them makes sense.

What it’s going to take to fill in your Lean Canvas


The key to filling out the Lean Canvas is interviewing your potential users. These initial interviews serve as a rough sample of your customer segment. The more users you talk to and the more that see the same problems you do, the more you can be sure you’re on the right track. But the truth is in the numbers. Talk to 5 potential customers and 3 agree? You might be onto something. Talk to 10 more and find no further agreement? You’re starting to get a feel for how pervasive your problem really is, or is not.

An initial online survey can help here. It’s faster than conducting 100 interviews and the Lean Methodology is all about speed. As a first step it can help you confirm interest level and even refine your market segment.

The final output – ready for prototyping

Coming out of this process, completing your Lean Canvas, your moment of inspiration has been tested, improved, focused. You had an idea and now you have a product concept you can clearly communicate to others — your team, your customers, your potential investors.

With a solid product concept you’re ready for the next stage — prototyping. Read an introduction to prototyping your app here.

Until then, if you have a product concept you want to take to the next level, get in touch. We’d love to talk about it with you.

(You can also start your lean canvas right now by clicking here.)

Agile basics for small businesses and start-ups

To understand Agile you need to understand where it came from. Building software is hard. You’re building a complex system. Bridges are complex systems, too, but they are regularly completed on time and on budget. So why does software development have a reputation unpredictable and unreliable?

The big reason is this: If you start on a bridge over a river, short of an earthquake, the other bank is still going to be there two years later when you reach it.

But in software and business, two years, even one year, is enough time for the ground to move underneath you. In two years your app might be obsolete or facing dozens of competitors. Or the underlying market has changed, your vision is outdated, and half of the software being built needs to be thrown out, another chunk needs to be updated, and your deadline is suddenly far behind the advancing market and user taste.

You end up chasing change, so busy keeping up that you never reach the finish line.

This is when Agile becomes an advantage.

Agile is not about building software as quickly as possible, it’s about releasing software as quickly as possible.

Agile and the MVP

Agile is where the Minimal Viable Product (MVP) meets Lean Business practices.

Following the MVP philosophy, your product might not be feature complete for years, but when it is developed with the Agile methodology, it will be delivering value to customers within weeks. That value will increase as the Agile team continues to incorporate feedback from users, build new features, and release them to the user base on a regular schedule with a shortened cadence.

Two weeks after launch, the search bar appears. Two weeks later users have a dedicated view of their favourite items and the search bar now has autocomplete.

By structuring development to deliver a new release every few weeks the MVP increases in value to its users, but continues to be an MVP. Because priority is given to value instead of features.

To find that value, Agile relies on User Stories.

What is a User Story?

A User Story is a high level description of what an app or web site needs to do written from the perspective of a user.

The classic format for a user story is “As an X , I want to Y, so that Z“.

Here are examples of two user stories:

“As a first time home buyer, I want to keep track of houses I’m interested in, so that I can buy my dream home.”

“As a real estate investor, I want to know average house prices, so that I can spot a bargain.”

User stories aren’t technical. They are meant to be discussion points between product owners/managers and developers. Separate to the discussion the developers devise a strategy to deliver the features that support the user story within a series of sprints.

What is a sprint?

A sprint is not a period of frantic typing and programming. It’s Agile terminology for the short block of time allocated to implementing features in an app or site.

Sprints tend to be 2 or 3 weeks long. This duration is a compromise between the challenges of software development and the drive to regularly add value to the users’ experience.

If a user story cannot be fulfilled within a single sprint it becomes an Epic. Epics take multiple sprints to complete. The challenge with Epics is maintaining that continuous addition of value to the users at the end of each sprint. It can be done. It just takes planning.

Hold up! Agile is more than User Stories and stand up meetings

“Working software over comprehensive documentation” is one of the four declarations from the original Agile Manifesto. It is not a rejection of documentation. The writers of the manifesto were all experienced programmers. They knew documentation was important.

But they created Agile at a time when the Waterfall Model was the leading methodology. In Waterfall, you plan and document everything up front. As if you were building a bridge and knew where the other side of the river is. And then your team worked methodically, step-by-step, over months and years, to implement the plan, complete the software, and release it to a market that no longer cared.

It was a methodology that sometimes saw projects spend months producing hundreds, even thousands, of pages of documentation before the first line of code was written.

Under Agile, the developers still need to know how the app is going to work, how it is meant to integrate with your business, and how your vision is to be supported.

Business rules still need to be provided, in all their detail. Wireframes need to be drawn and refined. Colours need to be specified.

Developers are in charge of implementation. You need documentation to provide the necessary details about the “what” they are implementing so they can focus on the “how”. It is one of the keys to being Agile.

Agile isn’t the solution to everything

Don’t make the mistake of looking at Agile and thinking it is a way of building software faster than normal. Agile brings responsiveness, not acceleration of software development.

That responsiveness requires experienced developers. Developers not just with a certification in Agile, but also years of experience with the technology and in delivering working software. It took years for the developers at SoftwareSeni to reach the level where they can deliver consistently. Learning Agile was a tiny part of that skill.

Responsiveness might also be what rules Agile out for you. If you’re not building software for a new market, or a market that is continually changing, traditional development models may work better and have a tighter fit with your company’s culture.

Your company’s culture might also be the thing that makes Agile the wrong solution for you. A top-down management style where decisions have to pass through multiple levels of stakeholders for sign-off is the opposite of Agile. Agile is about trusting the developers, trusting the conversations with product managers, and allowing a team to execute with minimal interruption.

If you’re already crafting the email chain in your head for feature sign-off, trying to implement an Agile process will be an exercise in frustration.

The last word on Agile

This article has given you the concepts you need to know when considering adopting an Agile methodology yourself. You hopefully have an insight into whether or not you can (or should) take advantage of it.

If you’re outsourcing your development, an Agile partner like SoftwareSeni can help you decide if Agile is appropriate. We’ll be happy to work with you, help integrate you into your own Agile team of developers, and apply this very effective development strategy to your competitive advantage. Get in touch.

How thinking like Frankenstein will help your MVP

What stage are you at with your MVP? Because the earlier you start thinking more like a mad scientist and less like a FAANG product manager the better your MVP’s chances of success are.

At the napkin sketch stage? Excellent. Wireframing? That’s great. Clickable prototype? Still got time. Coding? You might want to hit pause while you finish this article.

 

V is for viability

Viable in Minimal Viable Product does not mean that your product works. You’re not going to launch a product that doesn’t work. Viable means it fulfils the business goals you set for it. It is helping to answer the questions about your customers and your market that you created it to test.

The next iteration is also going to be an MVP. So is every iteration that follows as you close in on market fit and profitability.

How fast can you iterate? And how many iterations can you afford? Enough to find that market fit?

You don’t know. No-one ever does. The best you can do is iterate as fast as you can and minimise the cost of each iteration.

Which brings us back to Frankenstein.

Focus on creating, not re-creating

Frankenstein was focused on creating life, not hands or feet. 

You’re creating a product. A new product, never before seen. You don’t want to throw away time and effort re-creating the basic building blocks products are expected to have. 

You want to spend all the resources you can on your unique IP, the features that give life to your product. Everything else is product hygiene.

IP vs product hygiene

You want to minimise your spend on product hygiene. Product hygiene means your product meets user expectations. It has the features they expect. Those features work as they expect. If they need to register, they can register via an email, Google, Facebook, etc. When they go to make a payment, their preferred option is available and it happens quickly and smoothly.

It is a form of visual and functional competency. Professionalism. You can also think of it as table stakes for being competitive in the market. 

A big part of product hygiene is convention. Apps have been around long enough that everyone knows how they work and how they should work. 

When you prototype your MVP you want to split out what parts of it are product hygiene and what parts are secret sauce. 

The secret sauce is where you want to spend your effort and your money. This is your differentiating IP. 

Product hygiene – you want these parts implemented as quickly and cheaply as possible.

Build or buy?

This is where the Frankenstein approach comes in. You won’t be using body parts. You will construct your competition-stomping monster out of SAAS integrations, open source components, and third party libraries. 

Payments is the number one example of adding product hygiene using an SAAS. You could throw money and months at building your own payment system or simply integrate a service like Stripe.

At SoftwareSeni we draw the line between buy and build every day. And every day more features fall on the buy side.

The buy side includes free and open source software (FOSS). It has ‘free’ in its name, but integrating FOSS and maintaining it still costs money. 

Some of the common services we integrate so you don’t overspend on features that provide product hygiene but don’t contribute to your competitive advantage are:

Your moat, the features that make you stand out in the market and give you an edge, will need to be built by you and your team.

Building your moat

In the marketplace moats are built out of code. It can’t be avoided. Just ask Uber. Eleven years after launch, they still haven’t turned a profit, there are numerous competitors, and every local taxi company has a ride hailing app.

That’s a simplistic take, but it has a nugget of truth. If your entire feature set can be built from integrations and libraries you want to revisit your strategy and your idea.

Your moat will be built upon a framework. It might be WordPress, React, Ruby or Laravel. Your choice will depend on your own experience and your inhouse developers’ experience (if you have any). At SoftwareSeni we work across all the major application frameworks.

Your moat will be your entire UX and the business rules behind it. This is where you want to direct as many resources as you can. 

Integrating SAAS and FOSS doesn’t come free, but they represent hundreds of thousands of lines of code you don’t have to pay for or wait to be written. They also represent code you don’t have to maintain. In general, you can estimate that the ongoing maintenance and support of any code written for you will cost about 20% of the development cost per year. It’s just like maintaining machinery in a factory. Pieces start to rust and eventually stop working.  

Bolting together your first MVP, and the next

Hopefully this article has opened your eyes to a different approach to building your MVP. Thinking like Frankenstein, building with off-the-shelf parts whenever you can, will accelerate your path towards your MVP. It will shorten your iteration times and increase the number of iterations you can squeeze out of your budget.

Doing it well requires a wide knowledge of the libraries and services available and how they fit together. This is part of SoftwareSeni’s expertise. Collaborating with you to break down your product idea into the optimum combination of buy and build is a key part of our lean strategy.

If you’re at the sketch stage or ready to code, take a moment to talk to us. We’ll help you get more V into your MVP.

How to Choose the Right Developer (hint: Focus on Security and Support)

Choosing the right developer for your app or web site is a major decision. There are quite a few factors to consider – experience, technology, etc. The major factor, the one everything revolves around and your success depends upon, is risk. And how the developer manages it.

When we say “developer” we aren’t talking about a programmer you found on a freelance site who is eight time zones away and slow to answer your emails. We’re talking about an actual software development business with professional staff, standards, and a good reputation.

Website, web app, mobile app – they’re all major investments and key strategic moves. They need to pay off. You’re already taking a big risk in commissioning them. Why would you add to that risk by engaging a developer that offers no assurances, no protections and no process for reducing the risk they expose you and your business to?

This article is going to outline what you need to be looking for, and what you should be demanding, from any developer when it comes to risk. There’s a checklist at the end that summarises the things you need to be asking about.

Before the project starts

Ideally, you’re reading this before you have chosen your developer. Until you’ve been down this road a few times it can feel like you’re making a major decision based on screenshots of previous products, hand-picked quotes from clients, and a few paragraphs about how “agile” their development process is and how you will be in complete control.

That’s the standard messaging. Even we use it. It’s all true — our apps, sites and clients are real, and you need to be in the driver’s seat or it’s just not going to work.

But you need to ask deeper questions and demand evidence of professionalism. This is vital when you can’t visit their office and see your project being built in front of your eyes.

The clearest evidence for professionalism is risk mitigation. What systems do they have in place to mitigate the risks to you, their client? There will be a large overlap between their risks and yours. If they’re not taking care of their risks, how well can they be taking care of yours?

Here are some of the risk mitigation elements you want to see in place:

These are vital. Particularly Business Continuity Planning. It takes a team to consistently meet deadlines in this crazy world. While using a lone developer your business plans can be set back by them tripping over a cat. A team with strong leadership ensures you don’t lose forward momentum.

During development

When production begins on your app, from the very start, when ideas are being tried out in wireframes, you already need to begin thinking about the bigger picture. Does your developer have team members with this expertise:

After deployment

Once your product has been deployed and is enjoying a rush of traffic from excited users, it is now up to the dedicated DevOps team and good security protocols to keep you online. Your developer needs the people and expertise for around-the-clock monitoring and they need to be responsive to:

The strongest proof

Any developer can tell you they have all the necessary security policies in place. They can even show you their policy documents. But a developer serious about security will have a Compliance Officer whose role is to ensure that those policy documents are being followed on a day-to-day basis and are kept up-to-date.

The final level

Last, and certainly not least, you want to go with a developer who understands your business context. They should have an understanding of your local market conditions and be accountable under the same legal framework as you are. If you’re Australia-based the ideal is a developer with an Australian office and local staff. The clear communication and shared context in this situation can save you days if not weeks of time and frustration.

The developer trust checklist

Don’t let the number of things that can go wrong scare you off. Risks can be mitigated. An experienced, conscientious developer will be always working to minimise your exposure (and theirs).

Below is a checklist you can use to screen potential developers. Every item is mandatory. If a developer doesn’t tick all the boxes you are unnecessarily exposing yourself to failure. Whether that failure occurs before the launch or after depends on the item and luck.

Does your developer provide:

Forewarned is forearmed

Hopefully this information will save you some missteps on your path to building the dream app or site that your business needs and your competitors fear. There are thousands of developers out there. If you count the lone wolves on freelancing sites offering to build your app for cheap, then there’s hundreds of thousands. Choosing the right path is the most important decision you’re going to make. Even more important than picking a logo.

If you want to talk to a locally managed development team who ticks all the boxes, you can reach us through our contact page.

Everything you need to know about React Native apps – the business side

Forget the tech-speak. This React Native overview is for the business savvy, not the tech savvy. You’re here because you need an app if you want to stay competitive. And the app world is unknown territory for you. It’s a different landscape to the web. Different technology. Different, and fewer, service providers.

We know how it is. Choosing to invest in unfamiliar technology is one of those decisions that has a bet-the-farm feel to it. Right now you’re weighing options and worried that you’re about to throw away money, years, and your foothold in the market.

This article will help with your decision making. It’s going to start with a bit of history, so you have sense for the technological landscape. Then it’s going to give an easy-to-understand overview of the concepts behind the technology. Finally, it will cover the advantages of React Native, which are many, and the caveats, which are few, but for some businesses are deal breakers.

The React Native backstory

 

Credit: National Center for Supercomputing Applications/University of Illinois Board of Trustees.

30 years ago(!), in 1990, the first web browser was built. Not many people outside of hardcore geeks saw it. In 1993 the first popular browser was released: NCSA Mosaic, soon to be dethroned by Netscape Navigator. In 1995 Netscape introduced JavaScript to the world.

In the 25 years since, software engineers have been adding capabilities to JavaScript, mastering its potential, and trying to develop strategies to deliver an interactive, application-like user experience from a platform designed to display documents. React, which React Native is built upon, is the latest and currently greatest, manifestation of this.

React came out of Facebook and has been in use since 2011 and open source since 2013. React Native (an extension to React) has been used by Facebook since 2013 and was open sourced in 2015. At almost a decade of use, these are mature technologies powering big name sites and apps and supported by a rich ecosystem of add-ons and enthusiasts.

React was Facebook’s answer to the question – how do you deliver an immersive and responsive user experience inside of a browser?

The same question web developers have been asking each other since 1995. Each time the answer was a little better, giving incremental gains. This time, with React, the answer was revolutionary.

The technology behind React and React Native

At the simplest level, so simple it sounds unimportant, React is very good at telling the browser what exactly on the page needs to be redrawn. The less that needs to be redrawn, the faster the user interface – buttons clicking, timelines scrolling – can respond.

With React, your user can be typing into your search bar at the top of the page, reading the auto-complete suggestions pulled live from the server, while at the same time, at the bottom of the page, a like count updates on a photo. And nothing, except those two elements, a very small part of the overall page, gets redrawn.

It doesn’t sound exciting. But for developers it is. Because it comes along with a method of building an interactive website where React does all the tedious bookkeeping that keeps your site fast, while the developer does all the fun bits related to how it works and how it is structured.

The leap from sites to apps

With React handling the bookkeeping, developers could work at a faster pace and a higher level. That search bar at the top of your page? That could now be a component — a standalone piece of user interface that could be placed anywhere on the page, used anywhere on a site. It could even be open sourced and used anywhere on the internet.

The same with the three step wizard you use to sign up new users. Or a mega menu. Or a video player. Or a chat box.

It occurred to the React team at Facebook that what the code was doing in the browser — creating interface components out of HTML elements like <button> and <textarea> — could be done inside a mobile application. But instead of creating interface components out of HTML elements, it could simply use the native interface components — scrollbars, buttons, sliders, etc.

So React Native was born. At its heart is a virtual machine that runs JavaScript — all the code that covers your business logic, and it translates the calls to display pictures, text and interactive elements into displaying native user interface components.

React Native can be used to run the same code on Android, Android TV, iOS, macOS, tvOS, Web, Windows and the Universal Windows Platform (covering Windows 10, Windows Mobile and Xbox).

Depending on the product, anywhere from 60% to 90% of the code can be re-used from a React-based web app in a Reactive Native mobile app. This is one of the many reasons that at SoftwareSeni we advise clients to test their idea and prove their business case using a React web app – it’s an investment in reusable code in an environment where iteration can happen quickly. Much faster than with a mobile app, where the platform store review process can slow things down.

The React Native advantage

For someone wanting an app for their business, React Native has six major advantages going for it.

Maturity – computer years are even shorter than dog years. 7 years since launch and 5 years open source make React Native an established technology.

Popularity – developers love React and React Native, which means finding developers to build your app is not a problem. Finding good, effective developers — well, that problem never goes away.

Ecosystem – combine maturity with popularity and you get thousands and thousands of open source libraries that implement functions you want and need, dedicated tools and services, as well as experienced partners like SoftwareSeni.

Speed – building a React Native app is faster than developing an app in native code. Multiply that advantage by the number of platforms you’re launching on. And if you’ve started your journey with a React-based web app to prove your business case, the move to a mobile app is even faster. You’ve already done the hard work.

Cost – the speed advantage above should have already clued you in that React Native apps are cheaper than native apps. The availability of developers contributes to that, as does the deep ecosystem of re-usable code. Depending on the app and the team, they can be 2 to 10 times cheaper than native apps across multiple platforms.

Performance – because React Native uses the native components supplied by the device operating system, React Native apps run as silky smooth as a native app. They also get full access to all of the phone’s features — camera, microphone, location, etc.

React Native caveats

Nothing’s perfect. Great as React Native is, it does have a few drawbacks. The biggest one is that it is limited to certain kinds of apps. You wouldn’t make a game in React Native. If your app needs to do large amounts of drawing or manipulating things on the screen, you need to look at building a native app.

If you have an interface feature that React Native does not support you will have to get a custom native component built on each platform you plan to support. It is cheaper than building an entire native app, but it adds complexity and thus cost to the project. Involving SoftwareSeni during the design process can ensure you don’t accidentally end up in this situation.

Finally, a React Native app is only half of the customer experience equation. You cannot forget the backend. No matter what technology you use in your app the backend still needs to be built and that development time and cost is not affected by the app framework.

Take-aways

The take-away from all this is that React Native is a great choice for building an app, if not the best. The apps produced using the technology can stand shoulder-to-shoulder on your customers’ home screens with the likes of other React Native apps from Instagram, Facebook and Netflix.

Throw in the free cross platform features, allowing you to target the top end consumers on iPhones and the mass market on Android devices, and it becomes a no-brainer.

If you’ve been thinking of creating an app for your business, or if your business needs to be an app, get in touch and we can talk about the timeline options for getting your idea to market.