Mobile app implementation

Free consultation Projects

We build the app for iOS and Android, take it through to release on the App Store and Google Play, and register the developer accounts, certificates and signing key to your company. After the last release, your team ships the next versions without us.

We have worked with leading companies and startups

Challenges

Three moments when an app stops being an idea and becomes a decision

Not sure whether you need an app or a good mobile site is enough? Book a consultation - sometimes the honest answer is "do not build an app", and that is exactly what we will say.

  • „Customers ask for an app and you only have a website”

    Some features need the camera, background location or a notification at a specific moment, and a browser cannot carry that. There is also the shelf space - the store is where customers look for your brand when they cannot recall the web address.

  • „The app exists, but shipping depends on one person”

    The signing key sits on the laptop of someone who changed jobs, the store account belongs to the previous vendor, and the last update went out over a year ago. Regaining control of the release is then the work we do before adding a single new feature.

  • „The design is ready, nobody is there to ship it”

    The screens have been sitting in Figma for months because the product team has no capacity, and recruiting a mobile developer takes longer than the build itself. We pick up the finished design, ask about the states it does not cover, and take the thing to the store.

Who it is for

Who we run this engagement for

  • Companies with a web panel and work in the field

    The system runs in a browser, but the people using it are technicians, drivers or reps holding a phone and often out of signal range. The app takes over the part of the work where the camera, location and saving something without a network matter, and the rest stays in the panel.

  • Teams that inherited an app from another vendor

    The code exists, the app sits in the stores, but nobody in the company knows where the signing key is or whose name the account is in. We start by regaining control of the release and moving the app onto your accounts, because without that every fix depends on someone else's goodwill.

  • Startups before their first release

    There are dozens of features on the list and money for one release, so the most valuable thing is someone who helps cut that list. We pick a scope you can ship and maintain, and push the rest into later versions rather than into the first one.

  • Companies with an app for their own staff

    The app does not have to reach a public store, because a few hundred employees or selected partners use it. We then distribute it through the channels Apple and Google provide for that, and treat privacy and permission rules as seriously as with a public release.

Four printed interface layouts on a desk: a dashboard, a phone screen, a form and a table, with one block circled in marker

Our difference

What makes our engagement different

  • Accounts and keys are in your name from week one

    The Apple and Google developer accounts are opened in your company's name, and the signing key and certificates land in your password manager before the first build exists. Ending the engagement then means revoking our access, not migrating an app between accounts - which is a project of its own.

  • A submission prepared against review rules, not against hope

    The most common rejection reasons are known and published - no account deletion path, permissions without justification, a gap between the privacy form and what the app actually collects, sign-in walled off with no test account. We work through that list before we upload, and we run the correspondence with review ourselves.

  • We choose the technology after the scope, not before it

    A shared codebase shortens the build and the maintenance, but with heavy graphics, background work or tight hardware integration native code wins. We decide after going through the feature list, and we say plainly when your problem is not solved by an app but by a good mobile site.

  • We finish when you ship version 1.1 without us

    Hand-off is not a file archive - it is a release made with your hands in front of us: on a testing track, from the checklist, out of the pipeline you own. Until your team uploads a build on its own, we treat the engagement as unfinished.

Process

8–14 weeks from agreeing the scope to submitting in both stores

  1. Week 1

    Scope, platforms and the technology choice

    We walk through the feature list and cut what does not need to be in the first release. We decide whether the scope justifies native code or a shared codebase for both platforms, and which device permissions the app genuinely needs - every one of them has to be justified in the privacy form later.

  2. Week 1–2

    Foundation: repository, accounts, environments

    We open developer accounts in your company's name - an Apple organisation account requires a D-U-N-S number, which we apply for early because it can take several days. We generate certificates and the signing key, split test and production environments, and set up builds from branches.

  3. Week 2–9

    Building screens and integrations

    Screens ship in batches, and every batch ends with a build you can install on your own phones - not a screenshot in a deck. Integrations run alongside: sign-in, in-app payments, notifications, working with no signal and syncing once the network returns.

  4. Week 8–11

    Device testing and testing tracks

    The app goes to TestFlight and to internal testing in Play Console, so your team taps through it on their own phones before anyone outside sees it. We check different screen sizes, older OS versions, behaviour on a weak connection and after a permission is denied.

  5. Week 11–14

    Store submission and handing over releases

    We assemble the metadata, screenshots, privacy policy, App Privacy and Data safety forms and the account deletion path, then run the submission and the correspondence with review through to publication. Finally we hand over access, a release checklist and a session for your team.

Deliverables

Three things. The app, the release kit and control over shipping

  • App code for iOS and Android

    A repository in your organisation from the first commit, with screens, integrations and the states a design rarely asks about - no network, permission denied, an expired session. The choice between shared and native code follows the scope, it does not precede it.

  • A complete release kit for both stores

    Accounts in App Store Connect and Google Play Console, icons and screenshots in the required sizes, listing copy for store search, a privacy policy, the App Privacy and Data safety forms, age rating and an account deletion path.

  • A release pipeline and access on your side

    Automated builds and uploads, testing tracks (TestFlight, internal testing in Play), the signing key and certificates in your vault, a release checklist, crash reporting and a session after which your team ships a version on its own.

Toolkit

What we use

The tooling follows the scope, but this set comes back in every engagement - it is enforced by the rules of both stores, not by our preferences.

A workbench from above: two printed interface layouts, a magnifier enlarging one block, a steel ruler and a greyscale step wedge running from white to black, with one line underlined in orange marker
  • React Native with Expo or Flutter
  • Swift and Kotlin where the scope requires it
  • Apple Human Interface Guidelines
  • Material Design + Google Play policies
  • A release from a single command (Fastlane / EAS)
  • Crash reporting from day one in the store

Next step

Let us talk about your project

Tell us what you have to do. We will come back with scope and a quote.

Free consultation Projects

Selected work

Work from the products we take to the store

Projects from the product types where an engagement most often ends in a mobile release. Some apps are built under the client's own brand, and those we show during a consultation.

Projects

Outcomes

What you get, on what timeline and how you can check it

  • 2 stores

    We run the App Store and Google Play as one release - the same features and the same version number, two sets of metadata and screenshots

  • 8–14 wks

    From agreeing the scope to submitting both builds; the upper end is an app with sign-in, payments and offline work

  • 0

    That is how many developer accounts and signing keys stay on our side - the full set is registered to your company from week one, not from hand-off

  • 1 command

    That is what separates your team from the next release after hand-off - the pipeline builds the package and uploads it to both stores

The timelines come from the schedule described above on this page. We do not promise review times or the decisions of Apple and Google, because they are not on our side - what we promise is a submission prepared against the rules in force and correspondence carried through to publication.

Client voices

What our clients say

  • „Working with the Wzór team was a genuinely great experience! They always answered our questions quickly and were flexible about our comments. They have no shortage of creative ideas and are at the same time thoroughly reliable and on time. The end result fully met our expectations; we recommend them to anyone looking for professionals who care.”
    Maja Wieloch-Silecka Operations Director, Bosfor Group
  • „Our clients expect us to act fast and effectively across a very wide scope - from building a brand, through a website with a store, to running an effective sales campaign. Not an easy task, but doable when you have a tight-knit team and partners who take on challenges on the fly. For us, quality, accountability and commitment are key, and working with UX Agency Wzór gives us that 100%.”
    Piotr Alberski Chief Operating Officer, Agencja XO Media
  • „Our cooperation with UX Agency Wzór started with our own website. We really liked the way they work, so we decided to subcontract projects for our clients to them on a White Label basis. We loved their workflow, the way they hand projects over to our team, their documentation and their work on the design system. Now we can take on bigger risks.”
    Mateusz Swół Chief Operating Officer, Sellace

Time and scope

How long it takes and what drives the quote

8–14 weeks

Eight weeks is a narrow-scope app built on a finished design with a shared codebase for both platforms. Fourteen is a release with sign-in, in-app payments, offline work or industry requirements that have to be documented before submission.

  • The number of screens and the states each of them has

  • The integration scope - sign-in, payments, notifications, your systems

  • Whether the app has to work offline and sync once the network returns

  • The starting point - a finished Figma design or designing from scratch

  • Store requirements arising from your industry and the data you collect

FAQ

Questions that come up most often

How much does a mobile app implementation cost?

We quote each one individually, because the same brief can mean a twelve-screen app or a hundred-screen one. Five things drive the figure: the number of screens along with the states each of them has; the integration scope (sign-in, in-app payments, notifications, your systems); whether the app has to work with no signal; the starting point, meaning a finished Figma design or designing from scratch; and the store requirements arising from your industry and the data you collect. You get a proposal broken down by stage within two working days of the scoping call.

Native or one codebase for both platforms?

A shared codebase (React Native with Expo or Flutter) shortens both the build and the maintenance, because one fix ships to both stores at once - and that covers most engagements, where the app handles forms, lists, sign-in and payments. Native code in Swift and Kotlin is the choice where heavy graphics, sustained background work, tight hardware integration or OS features that land natively first are what matters. We decide after going through the feature list, not before it.

Can you guarantee the app will pass store review?

No, and nobody honest will. The decision and the review time belong to Apple and Google. We are accountable for what we control: before uploading we work through the most common rejection reasons - no account deletion path, permissions without justification, a gap between the privacy declaration and what the app actually collects, and sign-in walled off with no test account for the reviewer. If a rejection arrives anyway, we handle the correspondence and the fixes within the agreed scope.

Whose name are the store accounts in and who holds the signing key?

Your company's, from week one. We open the Apple and Google developer accounts on your details (an Apple organisation account needs a D-U-N-S number, so we apply for it at the start), and the certificates and signing key land in your password manager before the first build exists. An app signed with someone else's key cannot be updated later without that key - which is why we do not keep it on our side even for the duration of the project.

We only have a Figma design. Or nothing at all - can you still do it?

Both are fine. We take a finished design as it is and ask about what it usually leaves out - empty states, errors, no network, a denied permission. Where there is no design, we produce it inside the same engagement. If the app is to be another product alongside existing ones, it is worth starting with a design system, so the mobile and web screens do not drift apart after the first quarter.

Do we actually need an app?

Sometimes you do not, and we say so plainly. If the app would do what the website already does, without the camera, background location, notifications or offline work, then publishing it adds two review processes and an obligation to keep updating, without adding value. In that case a website implementation is faster and cheaper, and we come back to the app conversation once there is a feature a browser cannot carry.

What happens after launch - who ships the next versions?

After hand-off your team does, because the pipeline, testing tracks, release checklist and keys are on your side, and we run the last release before the engagement closes with your hands on the controls. Crash reporting stays in place, so you can see what breaks for real users. If you would rather outsource maintenance, we run it separately at an agreed monthly allocation - but that is a choice, not a condition for the app to keep working.

Related services

Related services

Book a free consultation with an expert to discuss your project and get answers to your questions.

- Patryk Korycki, CEO

Schedule a meeting
Book a free consultation