GBCORP BLOG · IT SERVICES
Build an App for My Company: Who Decides and Who Owns It
Someone at your company has said: we should have an app. If you are the person then asked to find out how, the first questions are not technical. They are who decides, who owns the result, and whose name goes on the accounts.
GBCORP builds and configures apps for companies. A company project differs from a founder’s in one important way: several people can say no, and nobody is automatically responsible for saying yes. Company apps fail less often on code than on unclear ownership, so settle that before asking anyone for a price. It takes an afternoon, and it makes every later conversation shorter.
Four roles to fill first
| Role | Decides | Without it |
|---|---|---|
| Sponsor | Budget and the final yes | The project stalls at every decision above the team’s level |
| Product owner | Daily choices, and testing each release | Developers guess, and the guess is discovered at launch |
| Operations lead | How staff work changes once the app is live | The app works, and nobody uses it |
| Account holder | Developer, domain, cloud and payment accounts | Accounts end up in the name of a contractor or a leaver |
In a small company one person can hold two of these roles. What matters is that each has a name beside it, and that the product owner has time set aside every week.
The one-page case
A company rarely approves “an app”. It approves a fix for a named cost. Write one page: the problem in a sentence, who has it, what it costs today in hours or lost sales, what the first release would do, what it would cost, and the figure that will show it worked. The same page helps with any supplier, because it turns “we want an app” into something that can be quoted.
The company accounts, opened early
Publish under the company from the start. Apple’s organisation enrolment requires a legal entity, a D-U-N-S number, a work e-mail on the company’s domain and a public website, and the name of that legal entity is what the App Store shows as the seller. Google Play organisation accounts also ask for a D-U-N-S number, which Dun & Bradstreet issues free of charge. Allow time, because neither the number nor the store checks are instant. Use a role mailbox rather than a personal one, so the account survives staff changes.
Checklist before the first call
- Name the sponsor, product owner, operations lead and account holder.
- Write the one-page case and have the sponsor read it.
- Apply for a D-U-N-S number if the company has none.
- Set up a role mailbox for developer and cloud accounts.
- List the systems the app must talk to, and who controls each.
- Ask the people who will use it what they would leave out.
The numbers to expect
Scoping takes one week, priced on its own, ending in a written scope and a fixed quotation. A custom first release takes eight to twelve weeks, with usable builds every two weeks. If a configured edition fits, it goes live within one to five working days on the web, with store listings after review, at a flat monthly plan. Customised or more complex functionality is quoted separately before any work starts.
A worked example
Consider a spare-parts distributor whose sales director returns from a trade show and asks the office manager to “look into an app”. The office manager starts with the one-page case and finds the real cost: two people spend most mornings answering dealers who want stock levels and order status. The sales director becomes sponsor, the office manager product owner and the warehouse supervisor operations lead, and the finance manager holds the accounts. The scoping week shows dealers need signed-in stock and order views more than they need a public app, so the first release is far smaller than the original request. The director approves it because the page gives a figure to check: morning calls in three months’ time. Dealers are invited in small groups, and the two people get part of their mornings back.
Getting finance to say yes
Finance teams dislike open-ended projects, and they are right to. Offer them fixed points: a scoping week with its own price, a written quotation for the first release and a fixed price for each release after it. Show running costs separately: hosting, store fees and support. Present the choice between a flat monthly plan, which looks like an operating cost, and a one-time or custom build, which may be treated as a capital purchase. Your accountant should decide the treatment, but the numbers should be ready when they ask.
Bringing staff along
An app changes someone’s day, and the people affected are seldom the ones who asked for it. Show them early builds and ask what they would change. The people who answer the phones know exactly which questions customers ask, and they will spot a missing field faster than any specification. When their work shifts from routine questions to the harder ones, say so plainly, and say what happens to their time.
The questions IT will ask
Where is data stored, who can reach it, how are leavers removed, how are backups tested and how would we leave? Answer these in writing before they stall the project. GBCORP builds on a cloud project in the company’s name, with roles, encrypted connections and backups, so the answers point to settings your IT team can inspect themselves.
Privacy and legal
Both stores require a public privacy policy, and each asks you to declare what data the app collects. Your legal adviser should check these texts against what the app really does, which is easier once the data list from the scoping week exists. Allow time for this in the plan, especially if the company has a formal review process.
If the sponsor leaves
Company projects outlast the people who began them. Keep the one-page case, the written scope, each release note and the account list in a shared place that does not depend on one person. Sign-ins on role mailboxes and a second administrator on each account make a change of staff a minor event rather than a lost project.
One app or several
Large companies often discover that customers, staff and partners each want something different. Resist building three apps at once. Choose the audience where the cost is clearest, release for them, and reuse the same accounts, rules and data when the next audience is added. A shared foundation makes the second app much cheaper than the first.
Ownership terms
The contract should name the company as owner of the source code, the cloud project, the domain, the developer accounts and the payment-gateway account, from day one. Documentation comes with every release. If your own team takes over later, the hand-over is a process with an end date rather than a dispute.
Questions we hear first
Who should sign the contract?
Whoever can commit the company and its budget, usually the sponsor. The contract should name the company, not an individual, as owner of the code and accounts.
We have an IT department. Should they be involved?
Yes, early. They know which systems the app must connect to and which security questions will come, and they may take it over later.
Can GBCORP open the accounts for us?
With the company’s authority, yes, and they stay in the company’s name.
What if the honest answer is that we do not need an app?
Then the first conversation should say so. A better website or a customer portal is sometimes the right answer.
Where to start
The GBCORP Custom App Development product is the priced starting point; the GBCORP custom app development hub sets out the method. For what happens next, read build a business app, from the problem to the first release, and for what it might cost, read how much it costs to build an app.
GBCORP operates across 17 countries on 4 continents through six pillars: AI & IT, Innovation, Sustainability, Infrastructure, Business Lounge, and EV's & Solutions.
