By Thomas Cohen, founder of Maestro
Build an internal application for a small team
Assign decisions, handle conflicting reservations and run a pilot: a practical guide to building a shared tool with the people who will use it.
Your team wants an internal application. Each person knows part of the work: schedules, requests or information that needs handing over. Before building, turn those expectations into shared decisions: what belongs in the first version, who can do what and how you will check the result when several people work together.
Follow a fictional community group that lends tools and runs repair workshops. Maya organises the sessions, Étienne looks after equipment and Alice welcomes participants. They work different hours and want a better way to manage reservations. The names, organisation and situations are invented to explain a method for a small team; this is not a customer testimonial.
1. Start with a handover that causes problems
Ask each person to describe a recent situation from beginning to end. Avoid starting with “we need a dashboard”. Find out who is waiting for which information, when they need it and what happens without it. A team’s need often appears between two tasks, when one person’s work has to become usable by someone else.
In this community group, Alice takes a drill request over the phone and writes it in a notebook. Étienne sees a drill on the shelf and lends it to someone else. The problem is not simply slow data entry: they do not share a confirmed reservation before promising the same tool to two people.
Reconstruct this task using examples prepared for the discussion. Where does the request arrive? Who confirms it? When does the equipment become unavailable? How is a late return reported? Record different answers. They reveal rules to agree on, rather than blame to place on a colleague.
Write one sentence describing the expected result: “Before confirming a loan, everyone must be able to see whether this tool is available for the requested period.” It gives the first trial a clear criterion. It also avoids building a feature-heavy application that leaves the original disagreement untouched.
2. Name who decides, contributes and checks
A small team can make decisions quickly if responsibility is clear. Choose someone to gather requests and decide the scope. That person does not own every idea. They prevent incompatible instructions from being sent in parallel to the person or agents doing the building.
Maya takes that role in our example. Étienne explains lending rules and checks equipment tracking. Alice tests reception and reservations. A suitably skilled person takes responsibility for technical choices and maintenance. One person can hold several roles, but none should remain unspoken.
- The decision-maker accepts a feature, postpones it or asks for clarification.
- Users describe the situations and exceptions they encounter.
- Reviewers try the tasks and record what actually happened.
- The maintainer prepares access arrangements, fixes and continuity measures.
Also arrange cover for the project lead. If Maya is away, who can approve an urgent fix and how much can they spend? A short written rule prevents the team from waiting for an informal message before every decision. The tool may help record choices; it cannot legitimately set your priorities for you.
3. Build a first version that connects roles
It is tempting to request one screen for each person: Maya’s schedule, Étienne’s inventory and Alice’s list. Start instead with a task that connects their actions. A useful first version would let someone request a tool, confirm availability, record collection and record the return.
That task should be complete within a limited scope. The group selects a few trial tools and leaves payments, membership and automatic messages aside. It is not yet replacing its entire operation. Write down these exclusions so that adding a screen halfway through does not quietly change the objective.
Prepare situations that require a decision: an ordinary loan, a late return, an unavailable tool and a cancellation. For each one, state the starting point, action and expected result. A mock-up can show the screens; these situations explain how the team expects the application to behave.
The nontechnical application brief helps collect this scope. Ask someone who runs a session but is not involved in the project to read it. If they understand what they will be able to do and what remains excluded, you have something more useful than a list of attractive feature names.
4. Agree on words and information
A shared application does not automatically reconcile different habits. Does “reserved” mean requested, accepted or already collected? Does “available” include a tool being repaired? Define the words before choosing colours. A clear interface can still lead to poor decisions if everyone interprets its statuses differently.
The group distinguishes “request received”, “reservation confirmed”, “tool collected” and “return recorded”. A tool under repair remains unavailable even when it is on the shelf. Étienne confirms which changes are allowed: a request can be cancelled; a collected tool needs a return or an appropriate incident report.
Give each tool a stable reference. Two identical drills must be distinguishable if their availability differs. Also decide what information is needed about the borrower. A free-text note must not become a place to collect personal details that serve no purpose in managing the loan.
Prepare a short glossary with an example for each status. Add who can correct a mistake and how to find that correction later. Keep this document alongside the application during trials. When a new term appears on screen, ask why it is needed before two competing descriptions of the same situation emerge.
5. Define access through actions
Write the actions each role needs: view availability, confirm a reservation, correct a return, export a list or manage accounts. “Team member” is too broad. Alice and Étienne may need different information even though they work for the same organisation.
The CNIL recommends limiting access to what the role needs and reviewing it. Turn that principle into situations your users can check.
In the fictional trial, Alice can confirm a loan but cannot change a tool’s repair status. Étienne can make it available after inspection. Maya can arrange temporary cover. Test both allowed and refused actions using separate accounts, including opening a link received from another user.
The end of a session or a volunteer’s departure also needs a defined process. Who reports the change, and who makes it in the application? Keep instructions appropriate to your team. A correct launch configuration will not necessarily remain correct if responsibilities change and nobody looks after access.
6. Plan for two people working on the same record
Alice and Étienne open the same availability a few seconds apart. Both still see a free drill and confirm a Saturday reservation. If the application accepts both requests without a check, the screens may look fine even though the group has just promised one tool twice.
Describe the rule before asking for it to be built: only one confirmed reservation may occupy this tool for a given period. The second person needs an explanation and a way to adjust their request. Do not leave them believing an action succeeded if it was refused or its outcome remains uncertain.
The PostgreSQL documentation on concurrent operations describes conflicts and necessary retries. Handling them depends on the application and needs technical verification.
Next, prepare a test with two accounts. Open the same slot, confirm almost simultaneously, then check both outcomes and the final list. Repeat with a cancellation and a late return. Your job is to validate the business behaviour; a technical person must check the mechanism that guarantees it.
7. Organise requests without changing direction every day
Keep one request list accessible to the people involved. Each entry describes the situation, consequence and desired result. A screenshot can help, but it needs an explanation. “Change this button” does not tell you whether the request addresses an error, an obstacle to use or a preference.
Alice asks for a button to extend a loan. Étienne objects because another reservation may follow it. Maya reframes the need: extend the loan only if the new date does not block a confirmed reservation. The discussion produces a rule instead of alternating instructions that undo the previous person’s work.
Order requests by their observed consequences: issues that block or corrupt a task, things that make it difficult, then improvements that can wait. Record the decision and its reason. A postponed idea stays visible without being promised for next week or reopened in every conversation.
Before making a change, ask which tasks it affects and which tests must be repeated. The guide to leading an application project builds on this organisation. Deciding fewer things at once mainly helps you know which change produced the result you are examining.
8. Separate project participation from using the application
Building together can mean watching a demonstration, commenting on a document or trying a version. It does not require everyone to use the creation tool or send instructions directly to agents. Choose participation that fits each person’s responsibilities, availability and the capabilities actually provided.
Maya could lead construction from her computer, then prepare a trial session for Alice and Étienne. Feedback goes into the shared brief before another request is sent. This can suit a small team as long as Maya’s absence does not make documents and decisions impossible to find.
The finished application must account for devices and locations: reception, the equipment room and perhaps home. Ask how everyone signs in and how information is shared. Building an application on a local computer does not automatically make it usable by several people or remove the need for a central service.
Try actual working conditions with fictional data: a small screen, an unreliable connection and someone returning after a week away. Note what is missing for them to resume work without a spoken explanation. These observations are often more useful than an abstract discussion of the tool’s theoretical user limit.
9. Run a pilot with a clear source of truth
Choose a limited period and a few representative users. State where the authoritative reservations are kept. Initially, the group can use fictional copies to validate tasks. During a live trial, it must decide where each piece of information is entered and how to avoid two contradictory lists.
Assign a pilot lead, a way to report problems and conditions for stopping. An unexplained double booking blocks progress. An unclear label needs a fix. A colour preference can wait. These criteria keep the final decision from depending only on the enthusiasm of the person who built the application.
- Alice reserves an available tool and finds the confirmation.
- Étienne tries to confirm an incompatible reservation and receives the expected refusal.
- A tool returned late remains correctly identified.
- Someone picks up a record after a colleague’s absence.
- A mistake is corrected and the result is visible to the relevant people.
Keep the result of each test, its context and the version examined. After a fix, repeat the affected tasks. Before expanding the pilot, ask what users still do elsewhere to finish their work: a parallel notebook can reveal missing information or a rule the application does not yet reflect.
10. Prepare for absences, incidents and maintenance
An internal application can quickly become essential. Describe what the team does if it cannot open the application, if information looks wrong or if the usual person is away. A short procedure should let people continue carefully, report the problem and recover entries made during the interruption.
In our example, Maya prepares a numbered fallback sheet for loans permitted during an outage. The group states who can use it and who will enter those movements afterwards. This fictional arrangement needs adaptation and testing: paper notes solve nothing if nobody reconciles them with existing reservations.
Name the person or contractor who maintains the software, the availability you expect and how to request help. Keep recovery instructions and access details in an appropriate place. Another authorised person must know how to find them without relying on messages scattered across several conversations.
Budget for maintenance and time to test after fixes. The difference between a prototype and a usable application becomes especially clear when several people depend on the same tool. Finishing construction does not end the decisions you need to make together.
11. Measure what changed in the work
Before the pilot, choose a few simple observations: reservations needing correction, information entered twice and requests requiring a call to a colleague. Keep the definitions unchanged during the trial. You can then compare situations without inventing a productivity gain merely because the interface looks more modern.
Ask Alice to show how she prepares a session and Étienne how he checks returns. Where do they still look for an answer? Which information do they distrust? Record their explanations. A tool can reduce one visible task while adding a less visible manual check for someone else.
Include the team’s time in the assessment: describing rules, preparing data, testing, training and corrections. If Maya avoids duplicate entry but spends every session explaining the application, the problem is not solved yet. That observation identifies a priority for improvement, rather than necessarily a reason to abandon the project.
12. Prepare the brief for agents or a contractor
Bring the need statement, roles, statuses, permissions and tests together in one shared document. Add postponed decisions and accepted limitations. Ask a colleague to find the rule for conflicting reservations without help. If the answer still lives only in a conversation, the brief needs a little more work.
Start with the free application brief template. Describe one request at a time, then ask for an explanation of the proposed behaviour before having it built. Agents can help prepare documents and code; team members remain responsible for business choices and approval.
Maestro lets you lead a project with AI agents on a Mac. That is not a promise of simultaneous editing between colleagues: your working arrangements and the finished application’s shared capabilities must be defined and checked. Begin with a pilot led by someone who gathers the team’s contributions.
As of 23 September 2026, Maestro is in an invitation-only beta for macOS 13 and later. The application is free during this beta, with AI usage billed separately; Windows is in development. The first result to aim for remains simple: complete a handover using the same information and a rule everyone understands.
Read the complete guide: build an application without coding