Customer portals, booking apps and Android and iOS apps for field and branch staff
Customer portals, booking apps and Android and iOS apps for field and branch staff all run on one backend. Screens are sized for entry-level phones. Networks are assumed weak. The apps are published under the client’s own Play Console and Apple Developer accounts, so neither the listing nor the signing key sits with a vendor.
- Designed for entry-level Android phones and weak networks
- Published under the client’s own Play Store and App Store accounts
- Source code, signing keys and documentation handed over
GullySystem work covers customer and staff apps such as parent apps for schools, document portals for professional firms and driver apps for transport operators. Booking apps serve clinics, service centres and membership businesses, while buyer portals serve builders and dealers who field the same payment and document questions every week. Some projects are a first app. The business has used only phone calls. Others replace a cramped mobile website. A few take over an app whose developer account and signing key sit with a previous vendor, so recovering access comes before any new feature.
Where Customers and Staff Still Depend on the Office
Field Work Reported Through Chat Groups
Technicians, drivers and site supervisors drop photos, voice notes and short messages into a chat group that someone in the office reads later and retypes as the day’s work. A customer who asks whether a visit happened is answered from a chat message, and no time-stamped record exists to check it against. Chat is not a record.
Documents Requested Again and Again
Staff hold receipts, test reports, warranty cards, agreements and statements, so a customer who misplaces a copy waits while someone searches a physical file or a year of chat. Nothing records what was sent. The next request repeats the search.
Booking Changes Handled at the Front Desk
Slots are given out over the phone, so every reschedule, cancellation and reminder becomes another call that someone at the front desk has to make or take. A freed slot stays empty. No-shows come to light only when the chair, bay or doctor is already sitting idle, and by then the next person waiting has not been rung.
No Presence on the Customer’s Phone
A website exists, but reaching it means finding an old link, logging in again and reading a page laid out for a monitor. There is no home screen icon. Nothing can send a notification. Between visits, the business is a saved link.
Entries Made Without Signal
Basements, warehouses, factory sheds, highways and rural routes all have weak networks, so an entry made there does not save and staff note it on paper. They key it in later. The records hold only what somebody remembered.
Registers Returning After Launch
An app that asks for many taps where a register took one line, or for fields nobody can know at that moment, loses to the register. Staff return to paper. It stays paid for and unopened.
Live Apps That Cannot Be Changed
Rates, timings and phone numbers inside the app are out of date, iPhone users cannot install it, and the store keeps flagging the listing. The store accounts sit in a former vendor’s name and the signing key is with that vendor, so even a one-line correction needs their cooperation. Nobody can fix it.
A new back-office screen will not fix this. Customers, field staff and branch staff hold different phones in different places, from a queue to a shed, so each needs an app built for that handset.
Web and Mobile Applications Built for the Phone in the Hand
The service covers the web and mobile applications that customers and staff use directly, namely a self-service portal, a booking flow, a field app and a branch app. Work starts by watching the job as it is done today, whether at a counter, on a bike or at a site, before any screen is drawn. Each screen has to beat the register.
Role-Specific Screens
One role, one job, one screen. A customer sees their own bookings, bills and documents, a technician sees the day’s visits, and a branch manager sees only the exceptions that need a decision. Each role gets a short screen built for one job rather than a crowded screen built for everybody, so a technician never scrolls past a billing tab.
Fast Entry, Including Offline
Defaults, last-used values, dropdowns and camera capture keep entry shorter than the paper slip it replaces, which is what decides whether staff keep using the app. With no signal, the same entry, photo or signature is stored on the device and synced later, and the screen shows what is saved and what waits.
Published and Owned by the Client
The Play Console and Apple Developer accounts, the signing key, the app listing and the source code all sit with the client’s own company, not with the agency. Nobody else holds the login.
What the App Changes in Daily Work
Focus on business value before discussing technology.
Customers Hold Their Own Copies
Each customer’s login holds their receipts, agreements, statements and earlier job records, so a copy can be downloaded late at night without phoning the office. Staff can see what was issued.
Visit Records Created at the Site
Check-in time, location, photographs and the customer’s acknowledgement attach to the job while the technician is still at the site, rather than typed up afterwards. A questioned visit can be checked.
Entries Held Until the Network Returns
Entries made in a basement, a warehouse or on a highway stay on the phone and upload when the connection returns, with a pending count visible on screen. No note gets copied out later.
Booking, Rescheduling and Reminders in the App
Customers book, reschedule and cancel against real availability. An opening can be offered to the next person on the waiting list, and confirmations and reminders go out from the system without a phone call.
Entry Compared With the Paper It Replaces
Each screen is compared with the slip or register it removes, then tried by real users before any development starts, so taps are argued over on a prototype. Usage is reviewed by role after launch.
Updates Published by the Client
Store accounts, the signing key and the source code sit with the client’s company, so a rate change, a fix or a new developer becomes the client’s own decision. Nobody asks a vendor for permission.
What Web and Mobile Application Development Includes
Everything required from operational discovery to production deployment and long-term maintenance.
User Research and App Scope
Work starts with the end users of the app, such as a technician on a route, a front-desk operator or a customer on a phone. Tasks become a signed scope.
Mobile Interface Design and Prototype
Screen flows and a clickable prototype open on a real phone, and two or three of the client’s own users test them before development starts. Changes at that stage need only a conversation.
Android and iOS Applications
Store-ready apps are built with React Native or Flutter, or in Kotlin and Swift where device features such as Bluetooth or background location require it. They are sized and tuned for entry-level handsets. Weight matters.
Customer Self-Service Portals
A secure login lets customers see their orders, jobs, dues, receipts, documents and complaint status, and raise a request without calling the office. Each login is personal.
Booking, Scheduling and Queue Apps
Slot and appointment booking runs against availability, rosters and capacity, with confirmations, reminders, rescheduling, cancellations and a front-desk view of the day. Double-booking is blocked.
Field and Route Applications
Assigned visit lists, check-in with location, photo and reading capture, spare or material consumption and customer signature all sit in one app. Offline entries sync later.
Staff and Branch Applications
Counter, warehouse and branch screens cover tasks done standing up, such as quick entry, scanning, verification and handover, with large buttons and no typing where a scan will do. Rights follow the role. Every change has a name against it.
Progressive Web Apps
An installable web app suits cases where two store apps are not yet justified, opening from a home screen icon with no download and no store approval. Nothing waits in a review queue.
Backend, APIs and Admin Console
Documented APIs sit behind the app. An admin console lets the client’s team manage users, content, masters, notifications and app settings without asking a developer to touch the code.
Notifications and In-App Messaging
Push notifications, WhatsApp, SMS and email are tied to events such as booking confirmed, technician on the way, document ready or payment due. Delivery status is recorded against the record.
App Store Publishing and Release Management
Store listing, screenshots, description, privacy policy, data-safety declarations, review responses and versioned releases are all set up in the company’s own developer accounts. The client signs in to see them.
Post-Launch Monitoring and Updates
Crash and usage monitoring, fixes for issues real users hit, and the compatibility updates that each Android and iOS cycle requires keep the app installable on newer devices. Neglect shows up as a missing listing.
Where Web and Mobile Apps Are Used
Real-world business processes we configure and automate.
School and Coaching Institute: A Parent App
A school office takes daily calls about fee dues, attendance and circulars, and reprints receipts on request, often for a parent who has lost the last copy. A parent app shows each child’s attendance, fee schedule, paid receipts, exam results, circulars and leave requests, with fees payable in the app. The office sees which parents were informed, and when.
Transport Operator: Driver App and Customer Tracking
A goods transport operator relays trip updates by phone, so consignors keep ringing the office to ask which stage a consignment has reached and when. A driver app captures loading, gate-out, breakdown and delivery proof with a photo and signature, holding entries offline on highway stretches. Consignors get a link for the current stage.
Facility Management Firm: A Resident App
A firm managing apartment complexes handles maintenance dues, complaints and visitor requests through one manager per property, so every request waits on one person’s phone. A resident app issues the monthly maintenance bill with online payment, takes complaints with a photo and follows each ticket through to closure. It also circulates notices. A resident can approve a visitor at the gate.
Builder: A Portal for Booked Buyers
A developer’s sales office takes regular calls about payment schedules, payment notices, construction progress and possession documents, each answered by hand from whichever file the executive can find. A buyer portal shows each unit’s payment plan, raised demands and receipts, dated site photographs, uploaded agreements and approvals, and a snag ticket after handover. Every demand and complaint is on record.
Staffing Firm: Site Check-In and Coverage
A security and housekeeping contractor deploys staff across client sites and confirms attendance by calling supervisors, and a missed post is discovered when the client complains. Guards use a phone app to mark arrival and departure with a location stamp and a photo, and an empty post raises an alert for the supervisor. Clients see only their own sites. Billing is raised from the attendance the system holds.
Car Service Centre: Booking and Digital Job Card
A multi-branch workshop takes service bookings by phone and calls customers to approve extra work, so a car can sit on the lift until the owner picks up. A customer app books a slot against bay and technician availability, shows the estimate with photos of what needs attention and takes approval in one tap. The ready-for-pickup message and a payment link follow.
Is This Service Right for Your Business?
We partner with established businesses that have outgrown manual processes and want reliable systems.
Businesses Holding Records Customers Ask For
Clinics, labs, workshops, institutes, professional firms and service companies whose customers need a copy of a bill, report, agreement, due date or job status. Today a staff member must be asked.
Companies With Staff Outside the Office
Technicians, drivers, collection staff, supervisors, surveyors and delivery teams whose work is reported by phone call, a WhatsApp photo or a slip handed in at day end. The office learns late.
Appointment and Slot-Based Operations
Businesses selling time, such as consultation slots, service bays, sample collection, classes, and court or hall bookings, where the diary at one desk is the constraint. Booking lives in one head.
Businesses With Continuing Customer Relationships
Schools, gyms, residents’ associations, maintenance-contract and subscription services, hostels and lenders whose customers return every month, and those customers need their own view of dues, documents and history.
Companies With a Back-Office System and No Front End
An ERP, billing package or custom system already runs inside, and what is missing is a customer or field app that reads and writes to it. No second set of records.
When an App Is Not Yet Needed
WhatsApp may already be enough. A small customer list that is content there will rarely open an app often enough to justify the build and the yearly store fees. If the requirement is one form, a responsive website or an installable progressive web app needs less build effort than two store apps. If internal records are still in spreadsheets, the system that holds the data comes first, because an app on top of nothing only collects what nobody processes. An unproven idea needs a focused first version to test demand, because a full app built on a guess only moves the guess onto a phone. This is stated before any quote.
Enterprise Capabilities in Plain Business Terms
OTP and Password Login With Session Control
Sign-in is by OTP, password or fingerprint. Device history and session expiry are recorded, and the login of a staff member who leaves can be deactivated at once, even if the phone is never returned.
Role-Based Screens
Customer, technician, supervisor, branch and admin users each get their own navigation, fields and rights, so nobody scrolls past screens that belong to someone else. Navigation stays short.
Offline Capture and Background Sync
Forms, photos, readings and signatures are stored on the device when there is no network and uploaded automatically afterwards, with conflict handling for two edits to one record. A visible pending count is included.
Camera, Scanning and Signature
In-app photo capture with compression for slow data, barcode and QR scanning, document scan and an on-screen customer signature are attached to the record they belong to. Photos are shrunk before upload.
Location and Geo-Tagged Check-In
Every visit is stamped with coordinates and time on arrival and departure. The app then orders the day’s route and totals the kilometres wherever a travel allowance is paid on distance.
Push, WhatsApp and SMS Notifications
Event-based alerts reach the right person, with deep links that open the exact booking, job or invoice inside the app rather than the home screen. One tap, one record.
Booking and Availability Engine
Slots are derived from rosters, bays, capacity and holidays. Buffers, blocked periods, rescheduling rules and waiting lists are supported, so a doctor’s leave or a bay under repair removes its slots automatically.
In-App Payments and Receipts
Cards, wallets and bank transfers run through the client’s own gateway account, and the customer gets receipts, part payments and a downloadable statement inside the app. Money lands with the client.
Documents and Downloads
Invoices, reports, agreements and certificates are generated as PDF in the client’s format and stored securely, with each file visible only to its own customer.
Multi-language and Simple Interfaces
Interface text appears in the languages users read. Large tap targets, icon-led navigation and short forms suit staff who are not comfortable typing, and the language can differ from one role to the next.
Version and Update Control
Staged releases, an in-app update prompt and a minimum supported version stop customers from transacting on an outdated build, so a corrected rate reaches every phone that transacts. Old builds get a polite block.
Crash, Usage and Adoption Monitoring
Crash reports name the device and screen involved. Usage by role and feature shows which parts of the app are in use and which are quietly avoided, so the next release fixes what people dodge.
Our Structured 6-Step Delivery Process
A transparent path from your first conversation to a reliable production release.
- 01
User Discovery and Journey Walkthrough
Time is spent with the people who will hold the phone, such as a technician on a route, a front-desk operator or a customer who currently calls the office. Inputs needed are access to two or three of those users, the questions the office answers every day, and any forms, job cards or registers they fill now.
- 02
Screen List, Roles and Scope
Every screen, user role, notification and offline behaviour is defined, along with the platforms in scope, which may be web, Android, iOS or an installable web app. The client signs the document. The client also supplies logo and brand files, plus content only the business can provide, such as terms, fee heads or service categories.
- 03
Prototype on a Real Phone
The interface is delivered as a clickable prototype that opens on a phone, not a slide deck, which cannot show how many taps a flow takes. Required from the client is a short session with two or three real users to tap through it, and one decision-maker to approve the design. Development then starts on a settled screen list.
- 04
Development in Working Releases
The app, backend, APIs and admin console are built in milestones, and after each one a test build is sent to be installed and used in real work. Test users must actually use it. Credentials are also needed for any system to be connected, such as billing software, a gateway or a messaging account.
- 05
Store Publishing and Pilot
The listing, screenshots, privacy policy and data-safety declarations are prepared, and the app is published under the client’s accounts, from a login the client controls. A Google Play account and an Apple Developer account in the company name are needed, with the documents they require. Guidance on creating them is provided. One branch pilots it first.
- 06
Rollout, Training and Support
Each user group is trained on its own screens and receives short guides in plain language, so a driver is never taught the billing tab. Support continues through the first live weeks. One internal owner for the app collects feedback and sets priorities, so later updates follow usage rather than individual requests.
What You Receive Upon Project Completion
Everything required to run, maintain, and expand your software without vendor lock-in.
Connects With the Systems You Already Rely On
We build bridges between your software so you don't have to replace functional existing tools.
Notifications and Messaging
- Firebase push notifications
- WhatsApp Business API
- Gupshup
- Twilio and SMS gateways
- Transactional email
Payments and Collections
- Stripe
- PayPal
- Adyen
- Bank transfer and QR payments
- Payment links and receipts
Business Systems
- QuickBooks and Xero
- Zoho Books and Zoho CRM
- Custom ERP and billing software
- Your existing website and database
Location and Mapping
- Google Maps and geolocation
- Route and geo-tagged check-in services
Identity, Storage and E-Sign
- Mobile OTP and Google sign-in
- S3-compatible document storage
- Digital signature and e-sign services
Selected for Reliability, Speed, and Longevity
Technology chosen to match your operational scale and long-term maintainability.
Mobile
Web and Portals
Backend and APIs
Data and Offline Storage
Delivery and Monitoring
Why Business Owners Choose GullySystem
Designed for Entry-Level Phones
Screens are checked on entry-level Android handsets with limited storage and patchy data, because those are the devices that technicians, retailers and customers often carry. A flagship phone is not the test.
Adoption Treated as Part of the Brief
Taps are counted against the register the app replaces. Real users test the design before build and usage is watched after launch, because an app nobody opens has failed even if every feature works.
Web and Store Apps Compared Honestly
If a responsive site or an installable web app fits the job, that is recommended instead of two store applications with their review cycles and yearly account fees. The honest answer is sometimes smaller.
One Team for App, Backend and Console
The app, the server behind it and the admin console are built by one team, so a form change never needs three vendors to agree.
Store Accounts and Keys in the Client’s Name
Publishing starts in the client’s own accounts. The signing key is handed over and the release process documented, so the client is not locked out of its own app.
Support Through OS Cycles
Android and iOS change their requirements every year. Support through those updates is available so the app can keep installing and meeting store policy after the project ends.
Flexible Engagement Options
Choose an engagement model that matches your operational scope, budget, and timeline.
Fixed-Scope App Build
Suited to projects where the screen list, roles and platforms are settled, with scope, designs, integrations and acceptance criteria agreed upfront. Commercials change only if the scope does.
Staff App First, Customer App Next
The internal app goes into daily use first, so real usage settles the data and the process before the customer-facing app is opened on that foundation.
Web App Now, Store Apps When Justified
The first release is a web app. It needs no download. No store reviews it. Android and iOS builds are added once real usage shows which features need a native app and which are fine in the browser.
Ongoing App Team
Suited to businesses running a live app. Regular releases, crash monitoring, store compliance and new features are handled by a team that already knows the product, so nobody has to explain the codebase again.
Frequently Asked Questions
Straightforward answers to the questions owners ask before getting started.
Should we build an app for our business, or is a mobile-friendly website enough?
Return frequency decides it. A website is enough for most first-time visitors, and an app earns its place when the same people come back often. An app suits weekly or daily use, or a need for the camera, location, offline entry, barcode scanning or push notifications. It also suits staff working in weak signal. A responsive website or an installable progressive web app suits occasional tasks, such as a form, an enquiry or a one-time booking. We say which side before quoting.
What does a web and mobile application project include?
A working product, not just an app file. The scope covers user discovery and a signed screen list, interface design and a clickable prototype, and the app itself for web, Android or iOS. It also covers the backend, database and APIs, an admin console, the integrations and notifications in scope, and offline capture where the work needs it. Store publishing under the client’s accounts, source code, signing keys, training and post-launch support complete the project, so nothing important stays with the agency.
How is the cost decided?
It depends on scope, not on a rate card. The factors are the user roles and screens, the platforms involved (web only, or web with Android and iOS), and the complexity of the rules behind the screens. Offline working, connected systems, payments inside the app and the amount of design work also count. Each adds screens, tests and store declarations. A staff app covering one task is a different project from a customer app covering a whole service relationship, with its own logins, notices and payments. An itemised proposal follows the screen list.
What decides how long it takes?
Scope and approval speed set the duration. The factors are the screens and roles, whether both Android and iOS are in scope, offline requirements, and any system whose credentials and approvals sit with someone else. Store review adds its own wait. Waiting for design approvals and for developer accounts to be created is a common source of delay, and neither can be hurried from our side. Putting one user group live first reduces that waiting.
Should the app be native, or built with React Native or Flutter?
It depends on what the app has to do. For most business apps, React Native or Flutter is the usual choice, because one codebase serves Android and iOS and handles camera, location, offline storage, scanning and notifications. That cuts the places a bug can hide. Native Kotlin or Swift suits apps that depend heavily on device hardware or background processing, such as continuous location tracking, Bluetooth devices, heavy media and specialised peripherals.
Will it work on inexpensive phones and on poor network connections?
Yes. That is a design requirement, not an afterthought. The app size is kept small, photos are compressed before upload, lists load in pages, and testing covers entry-level Android handsets as well as new phones. Where work happens in weak-signal locations, entries, photos and signatures are stored on the device and synced when the connection returns. A visible count shows what is still pending.
Who publishes the app on the Play Store and App Store, and what do you need from us?
We publish the app under the client’s accounts. The client needs a Google Play Console account and an Apple Developer account in the company name, each backed by company documents. The stores also want a public privacy policy page. Guidance is provided for both. Listing, screenshots, descriptions, data-safety declarations, review submissions and replies to store queries are handled by us, which saves the client from learning two consoles’ forms.
What do you need from us to get the project started?
Access to two or three real users, the forms, job cards or registers they currently fill, and one decision-maker who can approve the screen list and the prototype. Later stages need logo and brand files and content only the business can supply, such as terms, fee heads or service categories. Two store accounts are also needed. So are credentials for any system the app must connect to, such as billing software, a gateway or a messaging account.
Can the app connect to the software we already use?
Yes, apps connect to QuickBooks, Xero, Zoho, existing ERP and billing packages, the current website and database, payment gateways and WhatsApp Business through documented APIs, webhooks or a controlled bridge. The app then acts as a front end on the existing records and never keeps a second set of data, so the ledger and the phone cannot drift apart. Where a system has no API, exchange runs through scheduled sync or file transfer, and where the connection work is substantial, the API and system integration service covers it.
How is customer and staff data protected inside the app?
Access is by role. A user reaches only their own records. Data is encrypted in transit and at rest, tokens rather than passwords are stored on the device, sessions expire, and a lost phone can be logged out remotely. Only the device permissions the features need are requested and declared in the store listing, since both stores require a data-safety declaration matching what the app collects. A signed NDA is in place before discovery begins.
Who owns the source code, the signing keys and the store accounts?
The client owns all three. On handover the client receives the full source code repository, the app signing key and keystore, the backend and database, deployment documentation and intellectual property ownership. The Play Console and Apple accounts belong to the client from the day they are created, and hosting and gateway accounts can be in the client’s name too. A lost signing key is a serious problem in mobile development, so the key is documented and handed over as part of delivery.
How do you make sure our staff and customers actually use it?
Adoption is designed in and then checked. The prototype is tested with real users before development, entry steps are counted against whatever they use today, and first-time screens are kept short. At rollout each group is trained on its own screens and receives short guides in plain language, and the first rollout covers one branch or team. Problems therefore surface small. After launch, usage by role and feature is reviewed, and fixes follow what the data shows people avoiding, not what one stakeholder remembers.
What happens after launch, and do apps need ongoing work?
Yes, more than websites do. Android and iOS release new versions every year, stores raise their minimum requirements, and an app that is not updated can stop installing or be removed from the listing. A warranty period covers defects, then an optional support agreement covers crash monitoring, store compliance, OS compatibility updates and new features at an agreed cadence. An existing app from another vendor that is stuck starts with the software maintenance, support and rescue service, which first recovers the accounts and keys.
Read before you decide.
Practical notes on the questions this service raises, not product marketing.
Website Redesign: When Your Business Website Needs One, and When It Doesn’t
When a website redesign is worth it for a business, when it isn’t, what to check first, and how to redesign without losing your Google traffic.
CA Firm Website: What to Include and What to Avoid
What a chartered accountant firm website should include, what ICAI’s website guidelines mean for it, and how to collect client documents safely.
Lawyer Website: What an Advocate’s Site Can and Cannot Say in India
What a lawyer website in India may carry under Bar Council of India rules, what to leave out, and how to handle disclaimers and enquiry forms.
Architect and Interior Design Portfolio Website: What It Should Show
How to plan an architect or interior design portfolio website: project pages that tell a story, fast images, and an enquiry form that qualifies leads.
Let’s Build the Right Software for Your Business
Tell us about your current operational challenge, spreadsheet bottleneck, or software requirement. An experienced engineer will review your workflow and reply within one business day.
- No obligation consultation
- Senior engineer reviews your brief
- Your operational details stay 100% confidential
Start with your requirements
Seven short steps that tell us what you need. An engineer reads them before getting in touch.
Share your requirementsRelated Practices & Services
Custom Software and Product Engineering
The wider system behind the app, covering operations, masters, approvals and reporting, built around the way your business actually works.
UI/UX Design and Prototyping
Screen flows, interface design and clickable prototypes tested with real users before development budget is committed.
API and System Integration
Connect the app to your accounting software, ERP, payment gateway and messaging platforms so records move without anyone re-keying them.
MVP and Product Development
A focused first version to put an unproven idea in front of real users before committing the full app budget.