,

Why we (generally) don’t recommend React Native (or other cross-platform solutions) anymore

TLDR: frequent interminable library conflicts, deep knowledge of native platforms required to debug issues, and devastating edge cases result in no real difference it total cost of development with a huge increase in complexity.

In 2015, Facebook’s cross platform framework (meaning it could run on both iOS and Android), React Native, burst onto the scene and took the mobile world by storm. In the next couple years, big companies like Airbnb, Soundcloud, and Discord hopped on board, as well as more niche but influential companies like Artsy. People everywhere were drawn to the many potential advantages: shared cross platform code, the availability of developers, development speed, and the promised performance parity with native code.

By 2018, however, some of those big companies had begun abandoning React Native, Airbnb being the most visible of them, writing a large, multi part post-mortem on React Native at Airbnb. That year was also the peak of the search term, which has been declining since then:

LithoByte also experimented with React Native, and developed our in house expertise to the extent that we even accepted clients for the platform. However, we quickly abandoned the platform; let’s look at the reasons why. First, though, a brief history of mobile cross platform frameworks.

The History of Cross Platform Solutions

We at LithoByte have always been suspicious of cross platform solutions since the first few came out. In 2012, Mark Zuckerberg famously said that betting on HTML5 for cross platform capabilities was the biggest mistake Facebook had thereto made as a company. The problem was many-fold, but not least was that performance was poor compared to native development.

Xamarin was and is another cross platform solution, but never got the sort of attention that either HTML5 or React Native did – perhaps because it uses a less known programming language, is made by Microsoft, or some other reason entirely.

Fundamentally, though, what all cross platform solutions share is that they will, by definition, always be at least one step behind native, in a couple respects. First, there’s always some extra layer that translates the cross platform code into single platform code – this will always cause some sort of performance hit; you can minimize it, you can try to work around it, you can design your app to make it look inconspicuous, but it will always be there. Second, when native platforms update, people who use a cross-platform solution can’t use those features immediately – they have to wait for the solution’s maintainers to incorporate the new features into the solution, or they have to write their own incorporation code, which they’ll eventually replace with the official incorporation (which means extra effort with little pay off).

This is the largest thing a cross platform solution has to overcome to be, in our opinion, worth considering for general application development. The hype around React Native indicated that, because it uses native components in the UI, it didn’t have the same sort of performance hit as other frameworks, and because Facebook was creating it, there would be little or no slow down as the native platforms updated, which led us to give it a try in spite of our reservations. Unfortunately, neither of these have proven the case.

Our experiences with React Native

1. The 80-20 effect

With React Native and many other cross platform solutions, a developer can very quickly build about 80% of their app using the cross platform framework. This experience is revelatory for many, because making so much progress so fast is a level of productivity that we rarely experience. “Gee,” we think, “if I got this much done so fast, surely the last 20% will be just as fast – I just have to fix these small bugs here or there and I’ll have a whole app done in a very short period of time!” This experience often is what developers will base their recommendations on – 80% is a long way, and the experience is so convincing, that they’ll recommend a switch based on that alone.

Unfortunately, that last 20% is a nightmarish slog. Fixing one bug causes another. Upgrading a package to include a bug fix causes a conflict with another package. Making it look nice on one platform breaks the UI on the other. You start having to write more and more platform specific code to fix these issues, along with ugly code to accommodate strange work arounds. The time saved by the first 80% is often dwarfed by the time lost to the last 20%, making the investment of dubious value.

2. More native experience necessary than native development

Our developers report that because of the obscure and arcane bugs they ran into with React Native, they counterintuitively used more of their native knowledge than if they were just developing a native app. Crashes output messages that were opaque in the extreme, requiring a deep, expert level knowledge of the native stack (on both platforms!) to diagnose, with subsequent sifting through libraries touching that part of the native stack to hunt down the cause.

This meant that LithoByte could not hire junior developers to work on React Native projects, and instead had to rely on our most experienced programmers, driving up costs for our clients in both the short and long term.

Also as a result of this, we did not receive any benefits from the shared architectural style with the web framework React – simply knowing React was not enough to meaningfully contribute to a React Native codebase because of the deep native knowledge base required to debug. As noted in Airbnb’s posts about it, rather than reducing the number of platforms from two to one, React Native increased the number of platforms to three.

3. Ecosystem volatility

As an app progresses, both business and technical considerations drive the addition of new features. To provide those new features, new libraries are often required. Unfortunately, libraries vary vastly in many respects, including: maintenance consistency, dependencies, version requirements, stability, and more. Because of this, every time a new library is added, it may have a non-trivial impact on other libraries, as you may need to upgrade, downgrade, or replace existing libraries (and the code that uses them) to support all necessary features.

This makes adding new features harder and harder as time goes on, and is part of what causes the 80-20 effect described above.

One interesting story from Airbnb relates to a bug wherein, for some devices, React Native would render the app as all white – meaning you couldn’t see anything, since everything was the same color. The inexplicable solution to this was to turn off a library included by default in React Native called Fresco. To this day, Airbnb developers don’t know why that fixed the issue. Think about that: Airbnb has some of the best engineers in the world, competing for talent and hiring from companies like Apple, Google, and the creators of React Native, Facebook. If they couldn’t figure it out, most other companies couldn’t either – let alone a startup just trying to save money.

Conclusion

We find that generally companies looking to save money are better served by concentrating on one native platform before building out a second later rather than relying on React Native or any other cross platform solution.

That said, there are times a cross platform app makes sense: cases when you are building a very standard application that doesn’t need off the beaten path features, a small scale app that doesn’t need to be high quality, and cases when you rapidly need to build out a first version that you don’t plan on maintaining long term.

For some startups we mentor, a cross platform framework can be a great way to get a proof of concept out the door – however, they will most likely, at some point, need to re-write it natively. That costs more in the long run, but if a proof of concept is needed to raise money at all, then a cross platform framework may help you get there.

/by
,

Mobile App Startups: Marketing

There are a lot of choices when it comes to marketing your app.

The first and most obvious is the old gold standard: with word of mouth. This can be achieved in a few ways: obviously, you can make a product so good that users just have to tell others about it (this is very rare, especially for a brand new app). If your app is a communication service, to an extent word of mouth is built in: if your users need other people to have it in order to communicate with them, they’re more likely to spread the word for you. You can also build a social aspect to the application (and according to the excellent Gamefication by Design, you probably should be anyway), which, if natural, will allow your users to invite others or just generally give social proof to others that they’re using your app. Finally, you can attempt to build buzz with a beta, only offering a select number of invites to give the impression of exclusivity.

After the tried and true word-of-mouth, one of our favorites is by building something people are already searching the App Store for. This reduces your marketing strategy to one of App Store Optimization, with a side of App Store Ads, if necessary. (Note: App Store Ads are not always worth it – you’ll need to review your average revenue per user to determine if the cost of acquisition through ads makes sense.)

You can also try social media awareness and advertising. This involves creating social media accounts for your app on Facebook, Twitter, and the like, and posting, inviting people to like, joining groups, and generally interacting with potential users. This can be extremely effective, especially if you’re offering something that saves you customers time or money – however, it can also be an extremely intensive process, which can easily soak up a large amount of time, energy, and money.

Another option is search engine optimization and ads. Sometimes people aren’t searching the App Store for your solution, but instead they’re searching the web. If your website comes up at the top of those search results, you could get new users that way. If you’re publishing your app on Android, you can create a campaign with Google that can automatically detect where to place ads for you, either on the store itself or in web search results. On iOS, however, you’ll need to do your own research and place ads with Google accordingly.

You might also try affiliate advertising. With this strategy, you connect with influencers or folks whose audience you’d like to reach and offer their users a discount that also gives money to the influencer – this creates an incentive for the influencer to talk about your product, and the users that come to the app through that person/organization get a nice discount while allowing them to support the influencer/creator monetarily when they may not have been otherwise. Because you’re getting paying customers, it a makes up for the money you’re paying the spokesperson, but if none of their audience uses the affiliate link/code, neither of you will make any money from it, so choosing your desired audience carefully is key.

You could also try for paid or earned news coverage – though, as a startup, earned coverage can be hard to get if you don’t already have connections to a reporter or news organization. Similar to affiliate marketing, this may or may not be effective, depending on if your potential users read the news organization your company is featured in. Most news sites, stations, and papers will allow you to pay to be featured as well – but again, choose wisely if you want to see a return on investment.

Marketing is an art and a science, and should not be taken lightly. Excellent apps have been made or broken based on their marketing strategy, and we highly recommend thinking long and hard about how you want to approach it – including speaking to experts on the subject.

/by
, , , ,

Client Spotlight: Tapper Legacy

We’re delighted to announce the launch of Tapper Legacy!

Tapper is an incredible opportunity to share your stories with your family, friends, and loved ones. You will never have to leave anything unsaid or any story untold. It’s an app where your legacy can live on for generations to come.

We built this app for Tapper Technology from the ground up as a foundational product – meaning they will be able to reliably build upon it into the future. With a tech stack including Rails, Swift on iOS, and Kotlin for Android, we were able to quickly and cheaply build an MVP that will allow them to hire from a large pool talented developers internally when the time comes, quickly iterate on new features, and not sacrifice on quality.

Download the Tapper Legacy app today and start safeguarding your legacy!

/1 Comment/by
,

QA for Startups

Quality Assurance, or QA for short, is an important part of any app development process. QA helps identify potential issues before your app gets in front of users, which results in happy customers, more revenue, and lower development costs in the long run.

However, QA can also be a significant cost for a startup, depending on how much confidence in a product stakeholders require. QA can involve anything from just having someone open the app before you hit the final publish button all the way through a full-on QA Engineer writing extensive amounts of code that verifies the functionality of other code.

What it should not include, however, is developers spending cycles attempting to find bugs in the application they wrote. There are a few reasons for this.

First, developers are often one of the largest expenses in creating an app. Having your most expensive worker doing things that others are just as qualified to do is a recipe for going over budget.

Second, developers are notoriously bad at finding bugs in their own work – and it’s not because they’re stubborn, as tempting as that is to believe. The issue is that, as the architects of what actually appears on the screen, they have internalized the ‘proper’ way to do things. They know the way the system is meant to be used on an almost innate level, making thinking outside of that box difficult to say the least.

Third, developers think deeply about all the things that could go wrong in an application. Unfortunately, if they spent all their time preventing each of those things, the app would never be finished. Without a sense of how to prioritize various problems, developers will inevitably try to fix the wrong things – resulting in higher costs for the client.

As a result, LithoByte recommends one of two things: either including QA engineers explicitly in the project from the beginning, or have startup-internal contributors do some amount of testing themselves. If the former, startups should prepare for additional costs (though not as much as if they had no QA at all – you’ll pay for it now, or later, when your users report the bugs to you).

The latter (having a someone internal to the startup do testing), often means that the founder or a co-founder is testing out the application themselves. This is a good thing on several levels. As we’ve previously discussed in our article on bugs, founders often have a vision in their head of how an app should behave, but, through the process of reducing that vision to the imperfect medium of words, an incomplete version of that vision is communicated to the developers (not to mention the further translation into code). Having the founder frequently review the product has huge advantages, and allows the team to resolve discrepancies earlier in the process. This is often the cheapest, most effective way to accomplish QA.

Luckily, both Apple and Google have built in ways to test apps out before they get to live users. We highly recommend that, even if you have external QA consultants checking over the product, you also make use of the these tools to do internal testing by at least one stakeholder before releasing the application.

/by

Anatomy of a Bug

Many non-technical stakeholders believe a bug is exclusively the result of programming ‘mistakes.’ However, this is often not the case; there can be many causes for what people colloquially refer to as “bugs.” In this article we’ll go through some common ones, but first, let’s provide a definition of a bug.

What is a bug?

Fundamentally, a bug is a mismatch between how the user expects a product to behave and the way it does behave. (In fact, one of the most common formats for reporting a bug includes a description of the expected behavior and the actual behavior, both of which are required to specify the bug.)

Causes of bugs

Now let’s take a look at common causes for bugs, keeping the above definition in mind.

Programming for safety

Developers think hard about what can go wrong in a product, and how to prevent such situations from arising. In the process, programmers often make certain actions impossible, so as to prevent users from accidentally doing damage to the system. However, for an end user, this can be frustrating, and even result in a bug report.

As an example, imagine a product built to allow collaborative form editing: it has fields created by an admin, and workers fill out the form. Now suppose the admin decides that a field is positioned improperly, and so attempts to delete/recreate the field in the right place. When they go to save the revised form, however, the old field is still there. The company then reports this to their developers as a bug.

Is this a bug though? Let’s consider. When building the product, the developers considered data loss to be a worst case scenario, so they made it impossible to lose data (this is a good thing!). When the admin attempted to delete the old field, this would have resulted in all the previous data that workers inputted to it to be lost – so the system behaved as designed and prevented that loss.

However, obviously, this is preventing the user from doing something they want to do. It should be changed in some way or another. But ultimately, this isn’t a mistake per se – the system was behaving in the way it was designed, and it was designed in a reasonable way. While it was reported as a bug, it amounts to a new feature request.

Unsupported behavior

Similarly, sometimes a user will attempt to do something that the system does not support. As an example, consider a business equipment rental application, wherein a user can submit a request to their project manager to rent some equipment.

A bug is reported to the developers of the application: a user has attempted to submit a rental request repeatedly, but the application reports an error each time. However, upon further investigation, the user was attempting to insert emoji into the comment box – which is not supported by the database.

Is this really a bug? Had the consultant, from the beginning, suggested that supporting emoji be a top priority, the client would have balked – the application is for business purposes, so supporting emoji would be an unnecessary expense. If the client wants to support emojis, then that would reasonably be a feature request.

Overuse of a supported feature

If you’re familiar with the term DOS, then consider this as an accidental DOS attack. Sometimes users will make use of a feature far more than the developer (or business!) expected. For example, suppose a social media application has a feature wherein a user can upload a series of photos and the application’s server will generate a collage from them. As long as only a few people are using this feature at a time, everything works well – however, if the feature suddenly becomes very popular, it might end up overloading the server.

Is this a bug? If so, it’s a wonderful bug to have – it means that your service is popular! However, it obviously needs to be handled, and, again, a new “feature” would need to be requested to support the popularity of the collage making function.

Unexpected combinations of usage

Apps are complicated; they often involve tens or hundreds of thousands of lines of code. Users, too, are complicated. When these two sorts of complications interact, the results are often unexpected. We at LithoByte have often seen startups be shocked by how actual users end up using their app – not seldom is it ways that are completely counter to the way it was designed.

When a system’s features aren’t designed to be used together based on the client’s expectations of end user behavior, strange things can happen; and sometimes those strange things are reported as bugs. The important thing to remember here is that startups have limited resources – so planning for every possible use case is combinatorially, not to mention financially, infeasible. Again, if it comes up, it certainly needs to be resolved, but it is not a mistake, per se.

Miscommunications

When a startup founder describes their product, they have a complete vision of it. However, reducing that vision to the imperfect medium of spoken or written language will necessarily result in an incomplete picture. When a developer then takes that incomplete description and attempts to translate it into code, even more of the original vision will be lost. (This is one of the many reasons LithoByte recommends an iterative approach to development – it allows us to work with our clients to, with time, bring the actual application closer to their vision of it.)

Miscommunications are a part of the process and happen in every project. When a product is designed differently than the stakeholders intended, it is an opportunity rather than a failure. By allowing lots of opportunities to identify miscommunications, you end up with a better product overall.

Genuine oversights

Given the above, a relatively small proportion of ‘bugs’ are actually oversights or mistakes. However, every piece of software is imperfectly built – the question is not if a product has bugs, but whether they bother end users enough to cause a company to lose money. In this way, rather than trying to aim for a bug-free application, aim for one that users enjoy using. That doesn’t mean that everything they try to do with it will work – only that users will give you the benefit of the doubt. And when you run across a genuine oversight, which at some point you almost certainly will, it’s important to regard them as an unavoidable part of the process, fix them, and attempt to prevent them from happening again.

/by

Publishing your Android Application to the Google Play Store in 3 easy steps

This guide is intended to show you how to publish your Android application to the Google Play Store while following best practices.

Before publishing an app to the Play Store, you will want to create a Google Play account and pay the one-time developer registration fee of $25. Once you have this taken care of, you can move onto the developer console and create your first application. 

Suppose you have been working on application and you’re happy with how it currently works. After you have finished your  application and created a developer account, you will be faced with a somewhat overwhelming list of requirements, but fear not! We will guide you through everything 😄

Android Studio Bundling

In Android Studio go to Build>Generate Signed Bundle. This will launch a pop up and you should choose Android App Bundle because of Google’s new Dynamic Delivery Model. With the Android App Bundle, Google optimizes for each device that the app is launched on. APK is just a singular instance of your application.

Key Store Generation 

Every application you publish needs to be signed so that Google can verify that you, and only you, are publishing the app. In order to sign your application you can either let Google take care of it or you can have the key on your local machine. I am somewhat skeptical of Google so I would rather generate my own key and manage it.

1. Generate a key store which essentially behaves as a storage for all the unique keys of your application.

2. Create a key alias and a password.

3. Make sure that you check this box so that your key can be used in the Play Console.

Google Play Console

Hit the blue button that says publish an app on Google Play. You will need to check off the items from the left hand side before you can roll out your new app.

App Release:

Google has many tracks where your application can live. In this guide we will only discuss rolling your application out to production since it can very complex with A/B test, Alpha/Beta Launches, etc.

  • Production: In the second step of this tutorial we will talk about Android Studios Bundling feature that makes it simple to create and sign an app bundle. More about that later. After all the other steps are finished you will be able to rollout your app to production

Store Listing: (Everything in this section is required)

  • App Name: Short, sweet and memorable.
  • Short Description: 80 characters specifying the basic functionality of your app. Here is your change to give someone an executive summary of your application.
  • Long Description: Here you can give more in-depth details of your application and how you’re better than the competition!
  • App Icon: What people will see first in the Play Store.
  • Screenshots: Up to 8 screenshots per listing on the Play Store. Make them count.
  • Feature Graphic: Here you can display the key features of your application. It is recommended that you create a promotional video of your application in action to attract new users. Luckily Android has some tools that allow you to capture your app screen.Navigate to the bottom left of your Android Studio and click on the camera when you are ready to take a screenshot.

  • Content Rating: After you upload your application and fill out the content rating survey on the left side of your dashboard, you must assign a rating to your app. We recommend going with the rating assigned by Google since they ultimately control what gets published onto the Play Store.
  • Contact Email: If users need to contact you about any bugs in the application.
  • Privacy Policy: Many App Distributors require apps to have a privacy policy. Google requires a privacy policy for applications that are published on the Play Store. In our experience we find it best to hire a lawyer and create a general privacy policy for all the apps you would want to publish. This ensures that you are not vulnerable for any lawsuits in the future.

Content Rating

After you upload the Bundle in the App Release section, you will be able to establish the content ratings of your application.

This process is fairly straightforward and if you answer everything truthfully, you will have no problems!

App Content

Is your app safe for kids? Do you allow there to be harmful content? Are there any ads on your application?

Pricing and Distribution

Which countries do you want your application to reach? Is your app free or is there some fee? For now we will assume you are publishing a free application to all the countries in the world since paid apps introduce another level of complexity. Make sure your application is GDPR Compliant if you’re distributing to the EU.

Launch

After all these tedious steps, you are ready to roll out your app to the Play Store. Head to the App Release section and roll your app out. It will take about a day for Google to review your application.

After your app is public, Google provides robust data analytics and crash report data about your application.

/by

SUBWAY:NYC – a Better New York Subway App

SUBWAY:NYC is an app for the New York subway that gives you all the features you need while staying easy to use. The app provides everything you expect from an NYC subway app: an interactive map, train arrivals, directions, favorite stations; but it also gives you some features you won’t find anywhere else.

You know how you’ll be sitting on a train, scrolling through your phone, and waiting for the next gram to insta, but everytime you pull into a station you have to login to the wifi again? And then by the time you’re logged in, you’re already in the tunnel again? Well SUBWAY:NYC takes care of that for you: as soon as your phone connects to TransitWirelessWiFi we’ll log you in automatically.

And we all know how bad the train arrival estimates are on those little countdown clocks are – so we decided to crowdsource where the trains are. Now when you view a station we tell you if a train was spotted at a nearby station recently so you don’t have to guess.

Download the best New York subway app today to get all these features and more!

/by
,

Mobile App Startups: Tech Stack

Thryv gets many questions about this, especially from startups who are still looking for technical co-founders. Where should you start? What technologies are easiest to recruit for, and what are their tradeoffs? Well, this article should give you a good starting point.

Server

Your server is where you store all the data that needs to be displayed. Almost every startup will need a server.

The in-vogue thing to do at this point, especially if you’ll be building both a website and an app, is to build a JSON API that sits on your server. JSON is a common format for communicating between different types of applications, and an API is a set of capabilities that an outside application can utilize.

With that in mind, the question is often this: what’s the best way to build a JSON API? There are several options.

Ruby on Rails

Ruby on Rails, or simply ‘Rails,’ is a very common and reliable technology. Rails has the advantage of being quick to setup. It’s generally pretty easy to add features to a Rails API, and there are tons of developers who know how to use Rails. The disadvantages generally come as you get larger; Rails does many things for you, so doing more specific things can start being more trouble than it’s worth. That said, the speed you gain at the beginning can often outweigh the costs down the line, and many prominent companies use Rails at scale.

Node.js

Node can be a very advantageous technology to use, especially when the developers who are helping you work primarily on the ‘frontend’ of your website/app. Node uses javascript, which is a vital frontend web technology, but it uses it on the ‘backend,’ meaning that developers who generally work on one can easily get up to speed on the other.

Python (Django or Flask)

Python is a beloved programming language in many circles. Building websites and APIs in Python is enjoyable for many developers because it is so easy to work with. It also has some advantages in raw speed without sacrificing much in the way of development velocity. However, it doesn’t have quite the same developer pool as javascript, and it can be a bit more work than Rails to get something up quickly.

Database

The most common database format at this point is probably PostgreSQL. Postgres, as it’s colloquially called, is robust and professional, and belongs to a family called ‘relational’ databases. It can be a little tricky to setup, but it’s the workhorse of many modern server applications.

For specific types of problems, a non-relational database may be preferable. In those cases, MongoDB is probably the most popular choice.

App

When building an app, there are tons of choices. In Thryv’s opinion, though, there are only three good ones.

Going Native

This means programming in Objective-C or Swift on iOS, or Java or Kotlin on Android. Going native gives you the highest potential for a quality app. iOS and Android phones are built and optimized to run native apps well, so they’re always a safe bet, especially when you’re targeting only one platform to start. However, it can be difficult for small teams to rapidly iterate on two separate platforms, in which case it may be wise to consider a cross platform approach.

React Native

React Native is the latest in mobile development from Facebook. It allows you to quickly build native looking apps on both iOS and Android at the same time. Moreover, since it’s in javascript, you have a large pool of developers who can work on your app. There are, however, downsides. React Native does not match native performance, and there are certainly things that are difficult to do with it. Additionally, since it’s a part of the javascript ecosystem, things move very quickly, which means they break often.

React Native, in our opinion, is a classic high risk/high reward technology.

Flutter

Flutter is a new cross platform framework from Google. There are some large technical differences between Flutter and React Native, but they break down to two things: speed and styling. Flutter apps, due to Flutter’s architecture, will run smoother and probably be easier to build than React Native. That said, Flutter limits you stylistically: if you like Google’s Material Design then it will be a fast, easy to use option for you, but if you want to deviate from Material Design, you may want to consider React Native instead.

Web

There are so many options for building a website today. Most startups generally need at least a landing page, but if that is, in fact, all they need, there are a myriad of solutions that they can use: WordPress, Wix, Instapage, Squarespace… and many, many others. If you need to build a dynamic website, there are a few technologies people generally use. All the technologies mentioned in the Server section apply here, but it can be difficult to make them work with an API as we described. As a result, we recommend React for your dynamic website needs. React is the foundation on which React Native is built, so if you’re building your app in React Native, you maybe able to share code between them. Otherwise, you may also consider a framework called Angular. Both allow you to build beautiful, modern websites with the highest level of flexibility.

Infrastructure

Where should you host your web properties? There are two places we generally use (and, in fact, one is built on top of the other).

Most startups eventually move to Amazon Web Services (or AWS for short), and any tech person you talk to will have heard of it. AWS offers a lot of flexibility, and is excellent at helping you keep costs down. Unfortunately, it can be hard to setup, and there are so many knobs and buttons to tinker with that it can be quite intimidating.

For this reason, we often recommend that startups start out using Heroku, a Platform as a Service (PaaS) offering built on top of AWS which takes care of most of the configuration for you. Your developers will be able to easily deploy your code with few tradeoffs when it comes to performance and cost.

Need help?

Do you need help deciding what kind of tech stack you should go with? Then contact us! We’ll be delighted to chat with you about what you need, and help you get it done.

/by

Requesting new features for your app

Asking for new or different features in your app can be easier in some cases more than others. If you took our advice in Fixed Price vs. Time and Materials this just comes down to normal courtesy, politeness, and thinking things through. If you didn’t take our advice and signed a SoW with a strict, fixed scope, then this can be a huge issue which needs to be navigated carefully. Regardless, the process starts out the same, and it starts out with you.

Step one: Customer discovery

Do you really need this change? Have you validated it with your customers? How important is it to make this change? Making changes in the middle of a project can be dangerous, so doing at least some light research into how much you need to make the change is critical.

Step two: Business discovery

How hard is it to make this change? How much time will it take? How much will it cost? Businesses can often be surprised by how much work and money it takes to make what may seem to them to be a relatively simple change. Make sure you discuss such things with your development provider to determine what kind of complexity you’re dealing with, as this often affects whether you want to commit to it.

Step three: Timing the work

You’ve decided that you definitely need to make this change, and you’re comfortable with the difficulty level. Now the question is, when do you do it? Sometimes changes make more sense to do later, and occasionally even after launch of the product. It may also be easier to make the change after some other work is completed, which could save you time and money in the long run. As before, communicate with your development provider to fit the change into your development schedule.

Step four: Contract considerations (optional)

If you have a fixed price project, you’ll want to amend your SOW or, potentially, get a new SOW altogether if the change is large enough. This is one of the downsides to fixed price projects, since a) lawyers are expensive, and you may need one to review the new scope, and b) if the change needs to happen immediately, this process can really slow down development.

Every project will involve changes in scope and features, so keep this in mind when you’re considering signing a contract with a fixed scope, as it won’t truly reflect the reality of development. Regardless, if you follow these steps, requesting new features and changes to existing features will go much more smoothly for everyone involved.

/by
,

Google Play Indie Success Story Interview

In AppMaster’s podcast Google Play Indie Success Story with Elliot Schrock, host and marketing consultant Steve P. Young digs in to find out how some app developers are getting more success using Google Android revenue, and the hard lessons learned about choosing an icon for your app.

Founder and Mobile Architect Elliot Schrock is interviewed this week on the Appmaster.co podcast about his approach to market research, and user analytics… but on the way, he reveals his philosophy of taking care of users, applying the Golden Rule to app design, and his love of open source code.

And there’s a plug for one of the go-to apps on his phone you probably haven’t heard of. Hint: it makes you a better, more successful person.

Don’t miss his insights on:

  • App store SEO
  • User behavior
  • Selling apps
  • Prototyping and minimum viable products
  • Competitive research
  • Efficient coding

It’s just 36 minutes (which flies by), including the intro and outro.

/by