Your first mobile app with this studio

A first app should do one thing a stranger will pay for or return to. Book Thursday. See today’s orders. Show the member pass. We cut to that session, share one API with the website if you have one, and leave a release cadence you can keep. SYCGeeks has shipped product work from Vancouver since 2015. We will not hide a login behind six screens if the job is “book Thursday.” The catalog duration for a mobile application is twelve to twenty weeks, quoted in CAD, with iOS and Android from a shared app.

Write the first session as a sentence before we talk about stacks. “A regular books a 45-minute cut, pays a CAD deposit, and sees it in Square.” That sentence decides navigation, empty states, and whether you need accounts on day one. If two jobs fight — a social feed and a booking — we pick one for version 1. The other can wait for a quoted add-on after the stores accept you.

Native-feeling UI matters more than a novel stack. Tabs where people expect tabs. System type where it holds. A thumb can reach the primary action. We are not interested in a unique navigation theory for a first app. We are interested in a person on the SkyTrain finishing the task before Commercial-Broadway. If your reference is a consumer super-app, we will show you the subset that is your product.

Discovery is on Pacific time. Book a Square appointment without an account if you want to talk. Write admin@sycgeeks.ca with the job, the deadline, and whether Square, Stripe, or a warehouse already holds the truth. If an existing production app is down, call +1 (672) 200-7924 on a weekday. A first-app brief is not heat. A store rejection the day of a launch is.

We ship iOS and Android from one codebase when the product allows it. A first business app — booking, orders, a member pass, a simple catalog — almost always allows it. Two native teams and a second agency for Android is how a 12-week product becomes a 9-month argument about feature parity. We use the tools that get both stores shipped without that argument. You still get platform-native edges: push permission copy, share sheets, the way a back gesture feels.

When the product does not allow a shared app, we will say so in the CAD quote. Heavy offline maps, unusual Bluetooth hardware, or a game loop are the usual reasons. A marketing wrapper around your website is not a reason to go native twice, and it is often not a reason to go native once. If a well-made Next.js site with Square booking does the job, we will recommend the site. An app without a job is a souvenir.

One codebase does not mean one careless layout. Android system back, iOS safe areas, and notification settings differ. We test on a recent iPhone and a mid-range Android, because that is what Canadians actually hold. We do not test only on the designer’s device. Tablet layouts wait unless the job is a tablet job — a showroom catalog, a kitchen display. Phone first is the default for a first app.

You will not get a secret iOS-only feature in version 1 unless the store requires it. Feature flags that leave Android a week behind are how operators lose trust. If Apple Pay is in scope and Google Pay is not ready, we say that on the quote and we keep a card path. Wallets are extras. A card path is the product. GST/HST still applies to what you sell in the app.

Onboarding that explains your brand for 90 seconds is how people delete you. Show the task. If they must create an account, say why in one sentence — “so we can show your bookings” — and let them see the calendar first when the product allows it. We will not hide a login behind six screens. Magic links and Square customer records beat a password form you will reset every Monday.

Empty states are part of the first session. A new user with no orders should see how to place one, not a blank table. A booked user should see the next appointment in Pacific time, with a cancel rule you can defend. We write those states in English and French if both languages are in scope. French strings are longer. Buttons that fit “Book” may not fit “Prendre rendez-vous.” That is a design problem we solve before store screenshots, not after.

Permissions are asked at the moment of need. Camera when they tap to scan. Notifications when they book and want a reminder. Location when the job is actually nearby, not on first launch. Canadians are tired of apps that demand contacts on install. PIPEDA is about purpose. If we do not need it, we do not collect it, and the privacy text in the store listing matches the privacy page.

Offline and bad network are Vancouver facts — parkades, the Seabus, a shop on a concrete block. The first session should not die on a spinner. We cache the last booking, queue a failed submit, and show a readable error. “Something went wrong” is not readable. “We could not reach Square. Try again or call the desk.” is readable. That copy is in the project, in both languages if you bought both.

The mobile application includes one API the website can use later: versioned routes, written errors, auth for the clients you actually have. If you already have a site, we do not invent a second catalog. Square, Stripe, or the warehouse stays the system of record for money and stock. The API reads and writes those systems. Inventing a fourth truth is how you sell a jacket twice on a Saturday.

Webhooks from the processor belong in this design. A paid deposit, a cancelled appointment, a refund — those events should land where operators look, not only in a developer inbox. We give you retries you can see. Silent payment events are how care plans earn their keep. Monthly care is $450 CAD; yearly is $4,500. Watching the jobs that move money is part of that watch when the app is on care.

If you do not have a website yet, we still design the API as if a Next.js or WordPress front end will appear. Operators often need a desk view before they need another consumer surface. WordPress or Next.js depends on who will sit at that desk. The app is not the only client. Document the contract so a future developer can run it without calling us.

A custom API as its own catalog item is six to twelve weeks. Bundled with the app, it is in the twelve-to-twenty-week path. We will not hide an integration as “a small feed” in week eighteen. If partners must sign in, that is auth and a written error contract. Ask for it in the first brief. We quote it or we cut it. We do not surprise finance.

Accounts, notifications, and payments each add a week or more. Say which ones are launch-critical. A booking app that cannot take a CAD deposit is not finished if the brief said it would. A booking app that also wants a social graph, a chat, and a loyalty constellation is a different product. We pick the rail that matches the job: Square when you already take cards in a room, Stripe when subscriptions or a custom checkout live in the app.

Push is useful when it is a fact: “Your Thursday 3 p.m. is confirmed.” It is noise when it is a weekly promo. We implement transactional push first. Marketing push waits for a written decision and a way to turn it off. Store reviewers will look for that switch. So will PIPEDA-minded clients. Quiet hours should respect Pacific time unless the user is in another province and we stored that.

Payments in the app are Canadian payments: CAD, tax behaviour you decided, a receipt the buyer can read in the language they used. We test a real charge and a refund before we submit to the stores. A demo card in USD is not a test. Apple Pay and Google Pay sit beside a card path when the processor can settle them. We do not fake a wallet button in a webview.

Login problems after launch are usually the API or the database, not the customer. Readable errors, a way to write us, and a weekday phone for heat belong in the app footer. Wallet login, if you use it on the web, is a different product surface. Do not force a browser wallet on a hair client. Offer email or the Square identity you already have.

When we hand the app over, you get store listing support and a documented API. Screenshots, the subtitle, the first three lines that show before “more,” and the privacy nutrition labels are in the twelve-to-twenty-week path. They are not leftovers for a Friday night. Apple and Google reject listings that promise a feature the binary does not have, or that use another app’s screenshots. We write what the build does.

Canadian English and Canadian French listings are different products if you ship both. The French listing is not a thinner English. Keywords, subtitle length, and screenshot captions change. We need a signer for each language, the same rule as a bilingual website. Machine-translated store copy is how you get rejected or, worse, accepted with a listing that embarrasses you in Quebec.

Age ratings, medical claims, and finance language get a tighter review. If you are in a regulated profession, send the college rule in the brief. We will not “make the screenshots punchier” if the claim is not allowed. Accessibility in the binary — labels, dynamic type, contrast — is launch work, not a later package. Store reviewers and your users will both find the unlabelled button.

Developer accounts, tax forms, and the legal entity on the listing take calendar time that is not coding. Apple and Google want a Canadian business number, banking, and a person who can click “agree.” Start that in week one. We cannot submit from a personal account you share with a cousin. If the company name on the listing must match the GST registration, say so. We invoice you in CAD; the stores have their own fees.

App Review is a queue, not a button. Budget days, not hours, and do not schedule a press day on the same Friday you upload. We submit a build that matches the listing, with a demo account if login is required, and notes that tell the reviewer how to finish the task. “Test the app” is not a note. “Book the 3 p.m. slot with the demo user, skip payment with code QA-CAD” is a note.

Rejections happen. A permission string, a broken link in the privacy policy, a payment that does not complete in their region. We fix the defect inside the project. A new feature you thought of while we waited is not a rejection fix. That is a quote. The 90-day thinking from web work applies: defects versus new scope. We write which is which in the dashboard.

A release cadence you can keep is usually monthly or twice a month, not daily. Operators need a window to check Square and the phone. We leave a checklist: what to smoke-test, who can approve the store text, how to read a crash. Care covers watching crashes and small dependency updates in the reserved hour. A new screen is an add-on — extra work on the same project, about 25 percent less on care, or a block of eight reserved hours if it is bigger than an hour and smaller than a new build.

Version numbers should mean something to you. We bump the user-facing version when the task changes, not when a library patches. Release notes in the store should be in human language: “You can now cancel a Thursday booking from the home screen.” Not “Bug fixes and performance improvements” every time. People in Vancouver read those lines. So do reviewers the next time you need a fast review.

Launch support is for things that broke: a webhook that stopped marking Square appointments paid, a French string that overflowed on a small Android, a store listing that still shows an old screenshot. New scope — a second marketplace, a third language, a loyalty program — is a published add-on on the same project. We do not silently fold extra weeks into the original CAD number. That is how trust dies.

WCAG-minded work still applies on a phone: contrast, labels, dynamic type, and targets a thumb can hit. We test with larger text because operators in their fifties will use the desk build. Decorative motion waits. If a gesture is the only way to cancel, we add a button. Accessibility is product quality, not a PDF. A dedicated compliance program is a separate three-to-five-week engagement if you need a punch list beyond the launch bar.

Start with a brief a studio can price: the one job, the two stores, the system of record, the languages, the hard date. Send screenshots of the current process — the paper card, the Square POS, the spreadsheet. Book time on Pacific time if you want to walk through the first session on a whiteboard. We quote before anyone writes production code. A messy brief is fine. An invisible one is not.

If you already know you need the app this fiscal year, write that. Twelve to twenty weeks plus store review does not fit a fantasy date in four weeks. We would rather decline than miss. After you approve, we open the project in your dashboard, set the workflow, and book the first working session. You will always know the current step — intake, active, review, paused, launched — and why a week slipped if it did.

The short end of twelve to twenty weeks is for a ruthless product: one task, one processor you already use, English only, no custom hardware. Week one is the session written as a sentence and the API contract on a page. Weeks two to four are the shared app shell, auth if it is truly required, and the empty states. Weeks five to eight are the task, the CAD payment or Square booking, and the operator view. Weeks nine to twelve are listing copy, both stores, a real charge, and review. Content and approvals still move this calendar. A signer on holiday in week eleven will slip the stores.

The long end is honest when French is in scope, when Stripe subscriptions are the product, when a warehouse feed is dirty, or when you need a desk website in the same breath. Those are not surprises if they are in the brief. They are surprises if they appear in week fourteen as “small extras.” We will pause and write a number. Care members pay about 25 percent less on published add-ons; that discount does not make an extra marketplace free.

Students and extra hands, if they appear on your project, log hours with a general description another person can read. That is our internal rule and it is why an app project does not vanish into a black box. You will see notes: “Square webhook signed, refund path tested in CAD, French listing screenshots exported.” If a week is quiet, ask. Silent calendars are how app projects rot while everyone assumes someone else is in review.

When the stores accept you, the job is not a party. Watch the first ten real sessions. Read the crashes. Answer the first support email in the language it arrived in. If production is down, call. If you want a second task in the app, open the add-on on the launched project. You keep the history. You do not explain the business again to a stranger. That is the whole point of building the first app with one studio.