At some point in almost every web development engagement, the client asks about apps. The specific phrasing varies: "Should we have an app?" "Can you also build us an app?" "Our competitor has an app now, do we need one?" What happens next is usually one of two things: the freelancer says it is outside their scope and loses the revenue, or they say yes and outsource a project they do not fully control.
WebView app building is a third option that most web developers do not know exists. If the client has a working website, you can deliver a production-ready Android app without learning Kotlin, without setting up Android Studio, and without subcontracting any part of the build. The skill set required is the same one you already have: configuring a web-based tool and understanding a client's requirements.
What You Are Actually Delivering
A WebView app is a native Android shell that loads the client's website inside a full-screen, browser-free container. From the user's perspective it is a real app: it installs from the Play Store, sits on the home screen, and sends push notifications. From your perspective as the builder, the configuration is a series of fields rather than code.
What you hand to the client:
- A signed Android App Bundle ready for Google Play submission
- The app configuration saved on the platform and reproducible for future updates
- Firebase push notification integration, if required
- Guidance on Play Console account setup and submission
The fact that the implementation is a WebView rather than native Kotlin does not change what the client receives. They get an app that passes Play Store review and works on Android devices. The technology behind it is implementation detail that most clients neither know nor care about.
How to Price It
Freelancers who add app builds to their services typically use one of three structures, depending on how they want to position the service.
A one-time add-on to a website project: $200 to $500 for the base build, with optional additions for push notification setup ($100 to $200) and AdMob integration ($100 to $200). Your actual platform cost is approximately $10 for a Professional build (100 credits from the $15/150-credit pack). The pricing reflects two to three hours of your time plus the value you are delivering. Most clients do not comparison-shop app build services; they compare your price to the $25,000 agency quote they received last year and find it extremely reasonable.
An annual maintenance retainer of $50 to $200 per year covers rebuilds when branding changes, monitoring for Play Store policy updates that require configuration adjustments, and being available when questions arise. Most clients do not realize they want ongoing app maintenance until something needs attention and they have no one to call. This is a natural addition to any website maintenance package you already offer.
Bundled into higher-tier website packages: "Professional website plus Android app: $2,500." Adding a concrete, visible deliverable to a package increases its perceived value and gives clients something tangible to point to as a result of working with you.
The Account Structure Question
The most consequential decision in offering app services is where the app configuration and signing key live. Two approaches work, and they have meaningfully different implications.
On the client's own account: you do the configuration work in their WebToAppConvert account using their credentials. They own the signing key and the app configuration. Future builds and updates are in their control. You bill for your time rather than for platform credits. This is the cleaner structure legally and practically: the client owns their digital assets outright, the relationship is uncomplicated, and you do not create dependencies that become awkward if the engagement ends.
On an agency account: you maintain one WebToAppConvert account for all clients, use your credits for builds, and pass the cost through with a margin. Signing keys are managed centrally per client app. This scales if you are managing many clients and want to handle builds centrally. The operational requirement: when a client relationship ends, export their signing key and transfer it to them. They need it to continue publishing updates to their Play Store listing. Keeping a client's signing key when the engagement ends creates a dependency that is professionally uncomfortable and practically harmful to the client.
Signing Keys: Why They Matter More Than Most Freelancers Realize
Each app on the Play Store is cryptographically tied to its signing key. Whoever controls the key controls the ability to publish updates to that listing. If a client moves on and their signing key is sitting in your account without a transfer, they cannot update their app. Not delayed: not possible, without starting over with a new Play Store listing from zero reviews and zero installs.
Handle this from the beginning: one signing key per client app, documented properly with the alias, both passwords (keystore password and key alias password), and the exported keystore file. Store these alongside the client's other credentials in your project documentation. Treat the signing key with the same care you would give to a client's domain registrar credentials. It is that consequential.
The Workflow Per Client
- Gather inputs: website URL, desired app name, package name (for example,
com.clientname.app), a 1024x1024 PNG app icon, splash screen if desired, and the Firebase configuration file if push notifications are in scope. - Configure the app in WebToAppConvert: URL, branding, signing key, navigation rules, permissions.
- Run a debug build (10 credits) and install it on a real Android device. Share it with the client for review. This is the right time to catch navigation issues, rendering problems, or branding inconsistencies before a production build.
- Iterate on feedback. A debug build is cheap enough that a second round is not a problem.
- Run a Professional build (100 credits) once the client approves the debug version.
- Deliver the signed AAB plus Play Console submission guidance, or handle the submission directly if that is in scope.
Two to four hours per client is a realistic estimate for a clean engagement including communication, configuration, testing coordination, and submission support. At $200 to $500 pricing, the effective hourly rate is solid for work that does not require skills beyond what you already have.
One thing to confirm with the client before the first production build: the package name cannot change after a listing is published on Google Play. A new package name means a new listing starting from zero. Get the client's agreement on the package name in writing before you build.