At B7Dev, an app development firm


Chaim Sajnovsky works at B7Dev, an app development firm that instruments client apps, builds paywalls and rescues badly built projects. The most useful thing to learn from him is to charge early, keep the first version to one problem, and let measured onboarding and paywall data decide what to change.
you will do a company as a traditional company, just in a digital domain.
Avoid These App Development Mistakes
B7Dev adds tracking events to its clients' apps. The firm sets up the event tracking so clients can see what new users do. One client app averages 15 to 16 trial activations a day, reported by a daily Mixpanel email.
Firebase or Mixpanel can record every onboarding step. Without tracking, he says, you are shooting in the dark.
B7Dev built a remote paywall switch for a shared customer. The switch turns the paywall on or off without a new release. After it is on, every new install sees the paywall in onboarding.
It was built for a customer long ago, and it is cheap to build and shows results in a short time.
His firm gets a rescue project every week. The projects come from clients whose cheap developers produced apps that crash or do not do what the owner wanted. His firm offers a lifetime warranty on bugs.
The firm fixes bugs even when they show up years after launch. Fixes often mean rewriting part of the code or rethinking the app.
Put the paywall inside onboarding, before users try the app. Between 60 and 80 percent of the people who end up buying do so before they use the app. Developers who made the change saw an instant revenue lift.
Putting the paywall first feels backwards but works. Waiting until later gives up the largest group of buyers.
Test a hard paywall if the app gets about 20 downloads a day. A hard paywall has no close button, so users must start a trial to use the app. One client app went from $1,000 to $10,000 a month with the same downloads after tuning the paywall, raising the price and removing the X.
When that app briefly lost the hard paywall, sales fell to $5,000 for the month. Other apps reported three times more sales. It suits apps that need early revenue, for example to show investors before the next round.
Make the paywall remotely switchable and compare days with and without it. Run a day with the paywall off, then turn it on for everyone installing, and compare user behavior.
This gives a cheap, quick read on what the paywall is worth, without shipping a new version.
Ask for an App Store rating right after the paywall. About 1 percent of downloads leave a rating, so earlier asks mean more ratings. The average rating does not suffer as much as expected, and more five-star reviews come in.
Softer timings are the second app open, or right after a first action such as adding one to-do or finishing one meditation. Stores call early asks too aggressive, but not asking usually gets zero reviews.
Be aggressive in the first session, because even top apps lose users fast. Voodoo treats 40 to 60 percent day-one retention as a good rate, so the first session has to do the work on monetization and activation.
Track the whole first-time experience, not single screens.
Aim for a paywall view rate near 100 percent of installs. The rate is paywall views divided by installs or first opens. Since most people buy during onboarding, nearly everyone opening the app for the first time should see the paywall.
Track every onboarding screen to find where users drop. If 90 percent see the paywall but only 3 percent convert, the paywall is the problem. If users drop earlier, fix the onboarding screens.
Tracking replaces guessing with numbers about what new users actually do.
Test onboarding length both ways. One client cut onboarding from seven screens to four and conversions rose. Another client showed only a paywall, so three benefit screens were added before it, and overall conversions rose 234 percent.
Charge from the start to learn whether the app is a business. Free users do not prove anyone will pay. Chaim pushed back on a prospective client who wanted the first 100,000 users to be free.
Downloads are not users, and reaching 100,000 is hard. Revenue pays for more features and paid marketing.
Start with a high price and lower it later. He says ten people paying $100 beat a crowd paying less, and getting many people to pay little takes about twice the work.
His reasoning: "If you lower the price, the people will never love you. If you. If you raise the prices." A raised price makes customers unhappy, while a cut is welcome. He also says pricing is a large debate with no single answer.
Lock features and offer several purchase options. A geometry solver app went from $1 a day to $17 a day by locking certain features and offering options like remove ads and unlock all, with no extra downloads.
Options make people feel in control, since people dislike being told to pay or leave. He is also testing subscription formats beyond monthly, yearly and lifetime.
Buyers weigh the price against alternatives before paying. The negotiation is not a haggle with the customer. It is the buyer asking in their own head whether this is worth it, or whether something else is better.
Fewer paying users beat a big free crowd for a small app. Free users cost money to serve and pay nothing. Paying users give useful feedback and fund promotion and future versions.
Investors also want to see how you plan to monetize, not only free user numbers.
Launch with one core feature that solves one problem. Rev cut a busy app down to a record button, and usage, retention and revenue rose, since transcription is where it earns.
Founders pile on features because they doubt the idea. More features can come later, guided by what people actually use.
Test focus by explaining the app in about ten seconds. Describe the idea to someone else. If they do not get it, rephrase or rethink what the app does.
Users need to understand the app just as fast.
Ask for permissions only when the feature needs them. Rev asks for microphone access only after the user taps record. Collab Max asks for many permissions at launch with no explanation, which the host found confusing.
Mock up the idea and show it before building. Draft screens or a mockup and show them to people to see the flow and find pitfalls. Ask experienced people what they would charge or pay.
He also suggests seminars and conferences to meet people with technical, marketing and business experience.
Research top grossing apps and adapt what works. Look at which kinds of apps top the grossing charts, then improve on them instead of launching an untested idea.
Keep watching competitors, what they did and where they are now.
Soft launch to a small group so the app fails small. Release to volunteers, even friends and family. Ask whether they understood the app and how they completed a task, fix the issues, then send the new build to the same group.
He compares it to Hollywood closed screenings. "The good thing is to fail small and to get feedback and then move up."
Give users a simple way to contact you. An in-app email option lets early users send praise and feature requests. One past guest launched four apps, and emails from users of the one that worked, a quit-smoking-weed app, told him it was working.
Even harsh feedback is valuable, because silent users lead to a big failed launch.
Set user and retention milestones before launch. Define targets for users after a week and after a month, plus retention or time in app. Ask someone with data from similar apps what the real numbers look like.
Missing a target shows which area needs work or professional help. Comparing results with and without a marketing service shows whether it pays.
Get four or five quotes and ask why they differ. If one quote is very cheap, ask how they can do it and what warranty comes with the code. Do not take the first offer.
"Sometimes when you find. The cheapest one, you end up paying more in the long run." Once you find a good developer, stay with them.
Treat a warranty and ongoing support as proof a developer stands behind the work. His firm fixes its bugs for life. Skipping post-launch care risks bad reviews from a broken app.
Polish the idea on paper before asking for a quote. Sketches and screens expose missing pieces, and gaps found later change the quote. A solid idea gets a more accurate price.
Even pencil sketches count as homework, and early consultations are free.
Expect the first app to fail and keep iterating. Angry Birds was its studio's 51st app, Color Switch was its developer's 41st, and a past guest's hit was his fourth.
Each launch teaches how to work with Apple and Google, get approved and ship updates. Overnight hits exist but are the exception.
Run the app like a traditional company in a digital space. He says a startup exists to solve a problem, help people achieve something or entertain them, and needs the same factors as a brick and mortar business.
Big companies are rarely one-man shows, and no short programming course turns someone into a millionaire.
Four features to build into an app before launch: onboarding and paywall tracking, a paywall shown during onboarding, an App Store review prompt after the paywall, and a remotely configurable hard paywall. One client app went from $1,000 to $10,000 a month with the same downloads by optimizing the paywall, raising the price and using a hard paywall.
B7Dev adds tracking events to its clients' apps. The firm sets up the event tracking so clients can see what new users do. One client app averages 15 to 16 trial activations a day, reported by a daily Mixpanel email.
Firebase or Mixpanel can record every onboarding step. Without tracking, he says, you are shooting in the dark.
B7Dev built a remote paywall switch for a shared customer. The switch turns the paywall on or off without a new release. After it is on, every new install sees the paywall in onboarding.
It was built for a customer long ago, and it is cheap to build and shows results in a short time.
Put the paywall inside onboarding, before users try the app. Between 60 and 80 percent of the people who end up buying do so before they use the app. Developers who made the change saw an instant revenue lift.
Putting the paywall first feels backwards but works. Waiting until later gives up the largest group of buyers.
Test a hard paywall if the app gets about 20 downloads a day. A hard paywall has no close button, so users must start a trial to use the app. One client app went from $1,000 to $10,000 a month with the same downloads after tuning the paywall, raising the price and removing the X.
When that app briefly lost the hard paywall, sales fell to $5,000 for the month. Other apps reported three times more sales. It suits apps that need early revenue, for example to show investors before the next round.
Make the paywall remotely switchable and compare days with and without it. Run a day with the paywall off, then turn it on for everyone installing, and compare user behavior.
This gives a cheap, quick read on what the paywall is worth, without shipping a new version.
Ask for an App Store rating right after the paywall. About 1 percent of downloads leave a rating, so earlier asks mean more ratings. The average rating does not suffer as much as expected, and more five-star reviews come in.
Softer timings are the second app open, or right after a first action such as adding one to-do or finishing one meditation. Stores call early asks too aggressive, but not asking usually gets zero reviews.
Be aggressive in the first session, because even top apps lose users fast. Voodoo treats 40 to 60 percent day-one retention as a good rate, so the first session has to do the work on monetization and activation.
Track the whole first-time experience, not single screens.
Aim for a paywall view rate near 100 percent of installs. The rate is paywall views divided by installs or first opens. Since most people buy during onboarding, nearly everyone opening the app for the first time should see the paywall.
Track every onboarding screen to find where users drop. If 90 percent see the paywall but only 3 percent convert, the paywall is the problem. If users drop earlier, fix the onboarding screens.
Tracking replaces guessing with numbers about what new users actually do.
Test onboarding length both ways. One client cut onboarding from seven screens to four and conversions rose. Another client showed only a paywall, so three benefit screens were added before it, and overall conversions rose 234 percent.
Fewer paying users beat a big free crowd for a small app. Free users cost money to serve and pay nothing. Paying users give useful feedback and fund promotion and future versions.
Investors also want to see how you plan to monetize, not only free user numbers.
Common first-time app creator mistakes: too many features, no market research or goals, skipping soft launch, charging too late, expecting a hit on app one, and hiring the cheapest developer. Includes a case where a pricing and paywall change took an app from $1 a day to $17 a day with no extra downloads.
His firm gets a rescue project every week. The projects come from clients whose cheap developers produced apps that crash or do not do what the owner wanted. His firm offers a lifetime warranty on bugs.
The firm fixes bugs even when they show up years after launch. Fixes often mean rewriting part of the code or rethinking the app.
Charge from the start to learn whether the app is a business. Free users do not prove anyone will pay. Chaim pushed back on a prospective client who wanted the first 100,000 users to be free.
Downloads are not users, and reaching 100,000 is hard. Revenue pays for more features and paid marketing.
Start with a high price and lower it later. He says ten people paying $100 beat a crowd paying less, and getting many people to pay little takes about twice the work.
His reasoning: "If you lower the price, the people will never love you. If you. If you raise the prices." A raised price makes customers unhappy, while a cut is welcome. He also says pricing is a large debate with no single answer.
Lock features and offer several purchase options. A geometry solver app went from $1 a day to $17 a day by locking certain features and offering options like remove ads and unlock all, with no extra downloads.
Options make people feel in control, since people dislike being told to pay or leave. He is also testing subscription formats beyond monthly, yearly and lifetime.
Buyers weigh the price against alternatives before paying. The negotiation is not a haggle with the customer. It is the buyer asking in their own head whether this is worth it, or whether something else is better.
Launch with one core feature that solves one problem. Rev cut a busy app down to a record button, and usage, retention and revenue rose, since transcription is where it earns.
Founders pile on features because they doubt the idea. More features can come later, guided by what people actually use.
Test focus by explaining the app in about ten seconds. Describe the idea to someone else. If they do not get it, rephrase or rethink what the app does.
Users need to understand the app just as fast.
Ask for permissions only when the feature needs them. Rev asks for microphone access only after the user taps record. Collab Max asks for many permissions at launch with no explanation, which the host found confusing.
Mock up the idea and show it before building. Draft screens or a mockup and show them to people to see the flow and find pitfalls. Ask experienced people what they would charge or pay.
He also suggests seminars and conferences to meet people with technical, marketing and business experience.
Research top grossing apps and adapt what works. Look at which kinds of apps top the grossing charts, then improve on them instead of launching an untested idea.
Keep watching competitors, what they did and where they are now.
Soft launch to a small group so the app fails small. Release to volunteers, even friends and family. Ask whether they understood the app and how they completed a task, fix the issues, then send the new build to the same group.
He compares it to Hollywood closed screenings. "The good thing is to fail small and to get feedback and then move up."
Give users a simple way to contact you. An in-app email option lets early users send praise and feature requests. One past guest launched four apps, and emails from users of the one that worked, a quit-smoking-weed app, told him it was working.
Even harsh feedback is valuable, because silent users lead to a big failed launch.
Set user and retention milestones before launch. Define targets for users after a week and after a month, plus retention or time in app. Ask someone with data from similar apps what the real numbers look like.
Missing a target shows which area needs work or professional help. Comparing results with and without a marketing service shows whether it pays.
Get four or five quotes and ask why they differ. If one quote is very cheap, ask how they can do it and what warranty comes with the code. Do not take the first offer.
"Sometimes when you find. The cheapest one, you end up paying more in the long run." Once you find a good developer, stay with them.
Treat a warranty and ongoing support as proof a developer stands behind the work. His firm fixes its bugs for life. Skipping post-launch care risks bad reviews from a broken app.
Polish the idea on paper before asking for a quote. Sketches and screens expose missing pieces, and gaps found later change the quote. A solid idea gets a more accurate price.
Even pencil sketches count as homework, and early consultations are free.
Expect the first app to fail and keep iterating. Angry Birds was its studio's 51st app, Color Switch was its developer's 41st, and a past guest's hit was his fourth.
Each launch teaches how to work with Apple and Google, get approved and ship updates. Overnight hits exist but are the exception.
Run the app like a traditional company in a digital space. He says a startup exists to solve a problem, help people achieve something or entertain them, and needs the same factors as a brick and mortar business.
Big companies are rarely one-man shows, and no short programming course turns someone into a millionaire.