Three Weeks to Build, Three Weeks to Submit: Shipping a Native App Solo
A Note on Expertise
I'm not writing as an "expert" or claiming to have all the answers. I'm a builder sharing my journey on what worked, what didn't, and what I learned along the way. The tech landscape changes constantly, and with AI tools now available, the traditional notion of "expertise" is evolving. Take what resonates, verify what matters to you, and forge your own path. This is simply my experience, offered in the hope it helps fellow builders.
When Havnwright was first live, contractors could use it on their phones by opening Safari or Chrome and going to the website. It worked. The dashboard loaded. Basic features were usable. But anyone who has tried to run a real business from a mobile browser knows what I mean when I say "it worked" is not the same as "it was good."
Contractors are on job sites. They need a tool that feels like a tool, not a web page. That was the starting point for everything that came after.
The three paths I considered
Before I committed to building a native app, I tried the easier options.
Progressive Web App. The web version configured to behave more like an app when installed on a phone's home screen. I set this up and it was a small improvement. The browser chrome disappeared. It felt a bit more app-like. But the dashboard never stopped feeling like a website. For someone using it occasionally, it was fine. For someone running their business on it daily, it was not.
Capacitor. The next step up. You wrap your web app in a native container, and it behaves much more like a real app. Push notifications work. You can submit it to the app stores. I built multiple preview versions and tested them on Android emulators. It was close to a native experience. But after digging into what Apple and Google actually expect on the store, I realised something important. A Capacitor app that feels like a wrapped website is either going to get rejected in review, or it is going to get approved but miss the features that would make it worth having. I did not want to ship a half-baked product and have people's first impression be "this is just the website in an app."
Native. The proper version. Build it as a real mobile app using React Native, share the same backend as the web platform, and accept that the mobile experience needs to be designed from scratch for mobile, not ported over from a web dashboard.
I picked native.
The decision to share the backend
One thing that made this possible at all was that I had spent a lot of time on the backend of the web platform. All the authentication, the database queries, the business logic, the APIs. Those were already built and tested. The web app was essentially one frontend on top of that backend. The native app could be another frontend on top of the same backend.
That meant I did not need to reinvent any of the business logic. A contractor logging into the app would hit the same endpoints as a contractor logging into the web dashboard. Same data, same auth, same everything. The app just had a different way of displaying it and interacting with it.
This is the part that made a solo native app realistic. If I had needed to rebuild the backend as well, there is no way I could have done both in a sensible timeframe.
Building with Expo: a hundred builds and an Android phone
I used Expo and React Native for the app itself. I had dabbled with app development before over the years, mostly for myself, trying different languages and frameworks to understand what was possible. Java, Laravel and others I can no longer remember. I never went deep. This time was different because I actually had a product to build.
The development loop with Expo is its own thing. You make a change, you build a preview, you test it, you iterate. Sometimes the changes are instant. Sometimes you have to wait for a fresh build. I must have built a preview version a hundred times over the course of development, iterating on the UI, the flow, the way contractors would actually use it on a phone.
The hardest part of the build phase was not the code. It was the fact that iOS and Android render the same app differently. Something that looks right on my iPhone can look wrong on Android, and vice versa. I had been an iPhone user for years and I did not own an Android phone. I had to buy one specifically to test my own app.
That was an unexpected lesson. As a solo founder building for multiple platforms, you need actual devices for each one. Emulators help, but they do not catch everything. A test user on an actual Android device will surface things a simulator never will.
Throughout all of this, I was also talking to a head contractor who was giving me feedback on the workflow. Is this the order contractors actually do things? Would they use this button here, or would they never find it? That feedback shaped a lot of the final design. I changed the UI and the flow many times before it felt right.
Three weeks to build, three weeks to submit
The build phase took about three weeks. That was faster than I expected for a first native app, but it was possible because I knew what I wanted. The requirements were clear in my head and I was just translating them into code. The slow part was not figuring out what to build. It was dealing with Expo's build cycles and the iOS-versus-Android differences.
Then came the submission process.
If you have never submitted an app to the Apple App Store or Google Play, you do not know what you are in for. I had done similar things for the web. Privacy policy. Terms of service. Data handling documentation. Those existed already. But they all had to be rewritten in the specific language each store expects, with the specific structure each store requires.
Then came the forms. Tax information. Payment details. What data does your app collect. Why does it collect it. Who is it shared with. What is the age rating. What content does the app contain. Each question seems reasonable on its own. Put together, they are a wall you have to climb before you can even submit for review.
And that is before either store actually looks at your app.
Submission took another three weeks. Three weeks to prepare everything. Three weeks of forms, policies, certificates, screenshots, descriptions, and back-and-forth with both stores.
So for anyone who thinks "the hard part is building the app," I would gently push back. The building was three weeks. The submitting was three weeks. They are both the hard part.
The waiting game, and the back and forth
Once you hit submit, the control is no longer yours. You are waiting for Apple and Google to look at what you made and tell you what is wrong with it.
Apple was surprisingly fast. Most responses came back in 24 to 48 hours. Google was a bit slower, but also less strict about what they flagged. Neither of these is a bad thing. Apple is more thorough, Google is more lenient. They have different priorities, and once you understand that, you can submit to each of them with the right expectations.
What I did not expect was how much back and forth there would be even after I thought I had done everything right.
Before I submitted, I asked an agent to read through the full App Store and Play Store guidelines and tell me everything the app needed to comply with. I ran audits on the app multiple times based on those guidelines. I thought I had covered every corner.
I had not.
Apple came back with six rounds of rejections and fixes before the app was finally approved. Google came back with two. Each rejection was for something specific, something that only a reviewer looking at the actual running app would have flagged. The agent had read the guidelines. The automated audits had run. It still was not enough. There is a gap between "reading the guidelines" and "knowing what a reviewer will catch," and the only way to close that gap is to go through it yourself.
The payment layer is a whole separate project
If your app has any kind of monetisation, budget extra time. I did, because the contractor app has a subscription through RevenueCat.
Setting up RevenueCat itself is straightforward. Connecting it to both Apple and Google is where the work is. You have to configure in-app purchases in App Store Connect. You have to configure the equivalent in Google Play Console. You have to match those products to what RevenueCat expects. You have to handle the test flow for both platforms, which is different for each. And if anything is misconfigured, the subscription simply does not work, and you have to retrace every step to find which link broke.
Subscriptions are one thing. Paid-once apps are a different flow entirely. Refunds are another. There is a whole layer of financial integration that sits between your app, the stores, and your revenue system, and each piece of it needs to be wired correctly. If I had to do it all over again from scratch, I am not sure I could remember every step I took. Some of it only made sense in the moment.
That said, it was a good practice run. The next time I ship an app, I am confident the full process will take me about half as long. Not because the work is easier, but because I know where the traps are.
What I would tell someone about to do this
A few things I wish I had known before I started.
You need physical devices, not just simulators. Buy the phone. It is worth it. The bugs you find on a real device on a slow network are not the same as the bugs you find in a comfortable desktop simulator.
Budget as much time for submission as for building. If it takes you a month to build, assume another month for submission. Your policies will need to be rewritten. Your forms will need to be filled carefully. Your screenshots will need to be prepared for multiple device sizes.
Share the backend. If you have a web app already, do not rebuild everything. Let the native app be a new frontend on top of what you have. The data and business logic should be the same whether you are on a browser or a phone.
Accept that iOS and Android are different products. You are not building one app. You are building two that share a lot of code. Test both. Use both.
Do not ship something you would be embarrassed to demo. The temptation to just get a wrapped web app onto the stores is real. Resist it. People's first impression of your product on mobile matters, and a half-baked experience is worse than no experience.
Read the guidelines yourself, and expect reviews to find things anyway. Even with an agent reading guidelines and running audits, Apple rejected mine six times and Google twice before approval. Reviewers catch things that automated checks never will. Submit expecting rounds of back and forth, not a single approval.
Payments are a project on their own. If you are monetising through the stores, add meaningful time to your estimate for the payment layer. RevenueCat or whatever provider you use is the easy part. Connecting it correctly to both App Store Connect and Google Play, and testing the full flow on both, is where the days go.
This is part of a series about building products as a solo founder. Earlier posts cover my personal journey, why I built Havnwright, the authentication pattern, what building with AI actually looks like, and the memory system I built for my own AI workflow. The Havnwright contractor app is live on both iOS and Android.
About the Author
Alireza Elahi is a solo founder building products that solve real problems. Currently working on Havnwright, Publishora, and the Founder Knowledge Graph.