App Development

Every sound business in app development begins with one clear customer and one clear problem. In São Paulo and the wider state, demand is real but crowded, so a small, well-described customer group wins before a broad one.

• In app development: Find a user pain in one sentence; test with a clickable mock-up.
• Write the customer in one sentence: a user and a client. Add the place, the moment of need and what they use today.
• List five rivals or substitutes within reach. For each, record price, strength, weakness and how people reach it.
• Interview at least eight real customers with open questions. Record exact words, not your summary.
• Count the market in units: how many releases could one area buy in a month? Use two public sources and your own count, then take the lower figure.
• Choose one first segment and say why the others wait.

Activity. Write the one-sentence customer, a five-row rival table and eight interview records. Share them with a peer for a challenge round.

Standard to meet. Define a specific customer, build a rival table with prices, and trace every claim to an interview or a source.

Brazil asks every trader to be visible and accountable. Know which register, tax regime and sector rules apply before the first sale, and check each against the current official text.

• In app development: Data protection law (LGPD) applies; app stores have review rules.
• Choose a legal form: micro-entrepreneur (MEI) only if your activity appears on the official MEI list, or a company registered with a CNPJ. Regulated activities need their sector authorisation first. Check the current limits and lists on the official portal.
• Learn the tax regime that fits your size and write down which taxes you will collect and pay, and when.
• Find the sector rules for app development: licences, inspections, professional registers. List each with the office that issues it and the renewal date.
• Personal data of customers falls under Brazil's data protection law (LGPD). Collect only what you need, say why, keep it safe, and name who answers questions.
• Consumer law gives buyers clear rights on information, returns and complaints. Put your terms in plain Portuguese.

Activity. Build your own six-line compliance table for your first location. Mark what is done, what is pending and who confirms it.

Standard to meet. Cite an official source for every line, assume nothing, and date every pending item. Local law always wins over this course.

An offer states what the customer gets, how well, by when and at what price. For a working mobile or web app, the offer must make the quality visible and the next step easy.

• In app development: Define first release with must-have features only.
• Describe the core offer in three lines: what is delivered (a working mobile or web app), the standard it meets, and the time it takes.
• Add one proof for each promise: a sample, a test result, a guarantee or a customer record.
• Price from cost upward and from customer value downward, then pick a price inside both.
• Write a simple one-page terms sheet: what is included, what is extra, how to cancel.
• Create two options at most, so choice stays easy.

Longer notes. Interview five possible users and write down how each solves the problem today, with what tool and how long it takes. Pick one user and one result, then list the screens needed to reach it and cut every other feature. Draw those screens on paper and let users tap through them before any code exists. Estimate hours for design, build, tests and a month of fixes. Decide how the app earns: subscription, per-seat fee or service contract. Compare two similar apps and state your difference in one line. Read the store's review guidelines and the national data protection law before promising a launch date to the first client.

Activity. Write the offer card, the proof list and the terms sheet. Test them with three customers and note every point where they hesitated.

Standard to meet. Check that promise, proof and price are consistent, fit the terms on one page, and record three customer reactions.

Good operations make results repeatable. For app development, write each step so a new person could follow it on their first day, and measure each step.

• In app development: Sprint: plan, build, test, release, learn; keep a backlog.
• Map the process from first contact to paid and closed. Typical stages: enquiry, quote, preparation, delivery of the release, check, payment, follow-up.
• Name the key resource at each stage: a tested build and a backlog. Note what happens if it is missing.
• Write a one-page standard procedure per stage: who, what, tool, time, record.
• Choose three measures: speed, quality (errors per 100) and customer rating. Review them every week.
• Fix the cause of a defect, not the symptom. Ask 'why' five times and record the answer.

Activity. Draw the process map and write procedures for the two riskiest stages. Run each once and time it.

Standard to meet. Write procedures a stranger can follow, record weekly numbers for each measure, and trace one defect to a root cause.

The most serious risk in this field is a launch that users cannot use. A calm, written risk routine protects people first and the business second.

• In app development: Security bugs and data loss; code review and backups.
• List ten things that could go wrong. Score each for how likely (1 to 5) and how serious (1 to 5). Multiply and sort.
• For the top five, choose a control: remove the hazard, replace it, guard it, train people, or use protective gear, in that order of preference.
• Write who does what in an emergency, and rehearse it once a quarter.
• Keep an incident and near-miss log. Near-misses are free lessons.
• Check that insurance and legal duties match the risk you actually carry.

Activity. Build a ten-row risk register and a one-page emergency plan. Run a ten-minute drill with a peer and note two improvements.

Standard to meet. Rank controls by preference for the top risks, run the drill, and start the log. Where a regulation applies, follow the official rule.

People deliver the promise. Define roles, train to a standard and give feedback in the open.

• In app development: Train team on code standards and testing.
• Write a role card for each person: purpose, five tasks, the standard for each, and who to ask for help.
• Train by showing, doing with support, then doing alone with a check. Record sign-off per task.
• Set service rules for answering customers: reply times, tone, how to apologise and fix.
• Hold a ten-minute team check each day: yesterday's problem, today's plan, one risk.
• Build a growth path: what a new person can do in week 1, month 3 and month 12.

Longer notes. Name an owner for each decision: who sets priorities, who writes code, who tests and who answers users. Hold a fifteen-minute meeting each Monday where each person states what is done, what is next and what blocks them. Write acceptance criteria for each feature as a list of yes-or-no checks. Ask the support person to reproduce every complaint, then log the steps and a screenshot. Add a second pair of eyes to each change before release. Judge the team by problems solved for users, not hours worked. If freelancers join the team, a written contractor agreement and a clause on who owns the code come before the first commit.

Activity. Write two role cards and a training plan for one new hire. Role-play a hard customer conversation twice and review.

Standard to meet. Write role cards with measurable standards, show the sign-off steps in training, and write the service rules in plain words.

A business lives or dies on a few numbers. Know your contribution per unit, your fixed costs and the volume you need.

• In app development: Cost is people time; track burn and runway.
• Contribution per release = price minus variable cost. Fixed costs are paid whether you sell or not.
• Break-even units = fixed cost divided by contribution. Plan to pass it by a safe margin.
• Make a 12-month cash plan. Cash timing matters as much as profit: customers may pay late, suppliers may want money first.
• Keep money for business and money for the owner apart.
• Test the plan: what if sales fall by a quarter, or cost rises by a tenth?

Activity. Build your own table: price, variable cost, contribution, fixed cost, break-even and a downside case at 75% of sales. Show it to a peer or mentor.

Standard to meet. Calculate correctly, give every figure a source or mark it as an assumption, and show a downside case.

Growth should follow proof. Measure, learn, then add; and keep returning to the customer.

• In app development: Grow by usage data and retention.
• Pick one growth lever at a time: new customers, a higher repeat rate, a better price, or a new offer.
• Set one measurable target for 90 days, such as 'raise repeat customers from 20% to 30%'.
• Ask each customer how they found you, and record it. Spend more where the record shows results.
• Review monthly: numbers, defects, complaints, cash. Write three decisions each time.
• Plan the renewal of licences, equipment and skills a year ahead.

Longer notes. Add event tracking for sign-up, first action and return after seven days, and read the funnel every week. Group support messages by theme and fix the most common one first. Ship one small change at a time so the effect on retention can be seen. Show a new price to a small group before changing it for everyone. Ask active users for a rating at a happy moment, such as after finishing a task. Divide marketing spend by new users to learn the cost of each. Remove features nobody touches. Before charging a subscription, write the cancellation and refund terms in plain words and confirm how user data is stored.

Activity. Write a 90-day plan with one target, three actions and a review date. Present it in five minutes and take questions.

Standard to meet. Set a measurable, dated target, break the actions down small enough to start this week, and put the review date in the calendar.