Useforms
"Collect data wherever work happens."
Databeaver, the product now known as Useforms, was a form-creation and data-collection web app used across Nigeria's consumer goods and telecom sectors, but had no native mobile presence, form owners and respondents were tied to a browser.
How to read this case study: what I owned, what shipped and the verified outcome (My Role, What Shipped and Impact below) are factual. The surrounding strategy, vision, alternatives and metrics framework are interview-ready framing built on those facts, how I'd talk through the product thinking, not a claim that every metric or GTM motion was formally run at the time.
Challenges & baseline.
Challenges
Databeaver's web app worked, but it had no iOS presence, anyone creating or responding to a form on the move had no mobile option and had to find a browser. Data collection often happens away from a desk, which meant the environment where the information was actually generated determined the right platform, and the web-only product didn't fit that environment.
Baseline
Mobile access to Databeaver before this: none, web-only.
What the customer actually needed.
Insight
This is an engineering-role case study, not a Product Manager one, so the insight here is one I observed doing the work rather than one I set the product strategy around: data collection often happens away from the desk, and the platform someone can use in that moment determines whether the data gets captured at all. The right response as an engineer was native iOS parity, not a smaller web-wrapped shortcut.
Job to be done
When I'm creating or responding to a form away from a desk, let me do it natively on my phone instead of needing to find a browser.
Vision, mission & the bets we made.
Capture information wherever work actually happens, not just at a desktop.
Bring Databeaver's form creation and response experience to iOS natively.
Ship a native iOS app covering form creation and response collection; keep the iOS data model in sync with the existing web app rather than forking a separate experience.
Ship the iOS app with core form-builder and response-collection functionality; get it live on the App Store; keep it aligned with Databeaver's existing web data model.
Strategic bets
- Build native iOS rather than a wrapped web view, so the app felt like a real mobile product, not a shortcut
- Keep the iOS data model in sync with the existing web app rather than forking a separate mobile-only version
Alternatives considered
The faster technical option was a wrapped web view, ship sooner, less native work. That was set aside in favour of a real native iOS build, so the app felt like an actual mobile product rather than a shortcut, and so the data model could stay genuinely in sync with the web app rather than forking a separate mobile-only version.
What I owned.
Software Engineer, owned the iOS application for Databeaver end to end, the earlier product later redesigned and rebranded as Useforms by a different team. This was an engineering role, not Product Manager, and the case is written to preserve that distinction rather than inflate it.
What shipped.
Databeaver users could create and respond to forms natively on iOS instead of only through the web app, with the same underlying data model as the web product.
How it got built.
Scoped which web-app features needed a native iOS equivalent first, form creation and response collection
Built and shipped the iOS application to the App Store
Kept the iOS app's data model aligned with Databeaver's existing web app
How this reaches customers.
As an engineering contribution rather than a go-to-market decision, the logical distribution path would have run from existing web customers to mobile companion adoption to field teams to enterprise expansion. I wasn't the owner of that motion and can't confirm it happened this way historically, it's included here as the sensible next step for whoever owned distribution, not a claimed result.
North star metric.
Supporting metrics
- Databeaver gained a native iOS app alongside its existing web product
- Form creation and response collection both available on mobile, not just desktop
- Web/mobile data-model parity maintained
Guardrails
- Crash-free session rate
- Response error rate
The verified bottom line.
Gave Databeaver a mobile foothold it didn't have before, part of the foundation the product built on when it was later redesigned and rebranded as Useforms by a different product and design team.
What I'd do differently.
The right scope for a first mobile release is parity, not a reimagining, keeping the iOS data model aligned with the existing web app meant users never hit an inconsistency between platforms. It's also a reminder that not every product you help build carries your name forward, Databeaver's redesign into Useforms happened later, by a different team, and that's fine, the mobile foundation still shipped and held up. In an interview, this case is useful precisely because it shows product judgment (platform expansion, scope, parity) exercised from an engineering seat, not a claim to have run product strategy I wasn't accountable for.
More proof, more products.
See every product shipped and business built.