How to plan, build and review a Chromoly app

What should you define before building a business app?

Start with one recurring job and the people responsible for it. Write down the information that enters the workflow, the decisions someone makes and the result they need. A customer portal, for example, might collect a request, assign an owner, show a status and keep a record of the response. Agree which of those actions belongs in the first release and which can wait. This gives the project a useful boundary.

Use representative examples instead of a long list of feature names. Bring a sample spreadsheet with synthetic records, an existing form and the messages staff send today. Identify who may see or change each type of record. Define what counts as a successful outcome: a request reaches the right person, a customer sees the correct status and an administrator can investigate a failure. Record exceptions as part of the brief, including incomplete submissions and requests that need manual approval.

Describe relationships as well as fields. A customer may have several projects, and a project may have several requests. Decide whether a record can be reassigned, who can archive it and what should happen to related information. Agree the minimum information needed to create a valid record. This prevents a form from becoming a collection of optional fields that nobody can use consistently. A short example showing the same request before and after review often explains the rule more clearly than another feature list.

How does a design become a working app, website or portfolio?

A design describes the interface: pages, content, navigation, layout and appearance. The implementation also needs behavior. A contact button might open an email client, submit a form or create a request in a database. Those are different requirements even when the button looks identical. Decide what each important action should do and which information must survive after a visitor closes the page.

For a website or portfolio, begin with the audience and the next action you want them to take. Plan the home page, supporting pages, project details and contact route. For an internal app, start with records, roles and the tasks staff repeat. Review the design alongside these requirements so that attractive sample content is not mistaken for stored business data. A useful handoff contains the design, the page links, example records and a short explanation of the actions that need to work.

Include the states that are easy to overlook in a static mockup. Show what a new user sees before any records exist, what appears while an action is running and how a failed submission is explained. Check that important actions have understandable labels and can be reached on a phone. For a portfolio, supply real project descriptions and images you have permission to publish. For a customer portal, separate the public introduction from the pages that require a member account.

What does a realistic first-release example look like?

Atlas Operations, shown above, is a Chromoly demonstration with synthetic data. Its screenshot connects projects, tasks, risks and team capacity in one interface. It is a concrete example of the kind of connected workspace you can discuss with us, rather than evidence of a customer's financial results or a promise that every project needs the same modules.

An illustrative client-delivery brief could begin with a project register and an owner for each project. Staff would add tasks, record a risk and review work due this week. The first acceptance examples could check that a new task appears under the correct project, a restricted member cannot edit another team's records and an empty dashboard explains what to do next. Add invoicing or external notifications only when their rules and connected accounts are understood. This keeps the first release testable and leaves room to improve it after people use it.

A second illustrative brief is a request-and-approval portal for a small agency. A client submits a brief, a coordinator checks the information and a reviewer approves the next step. Write the permitted transitions down: submitted, under review, changes requested and approved. Decide whether the client can edit an approved request and what happens to the previous approval after an edit. The useful result is an explicit workflow with an accountable owner, rather than a status badge that changes without a defined business rule.

How should AI agents fit into a business workflow?

Give an agent a defined job, permitted data and a limited set of tools. A support agent could prepare a reply from an approved knowledge source for a member of staff to review. An operations agent could propose follow-up tasks for overdue work. Preparing a draft, changing a record and sending a message are separate actions; agree which are allowed and where a person must approve the result.

In Chromoly, the owner configures agent access, tools, budgets, triggers and approval rules. Generating an app does not automatically activate an agent. Start with a small task using synthetic data, inspect the proposals and run history, and confirm the cost and failure behavior before scheduling recurring work. Define what happens when a model is unavailable, the answer lacks evidence or a requested action exceeds the allowed scope. Retain a clear route for a person to take over instead of treating every AI response as an instruction to execute.

Evaluate an agent against a small set of examples before making it part of daily work. Include an ordinary request, missing information, conflicting instructions and a request outside its role. Decide which outputs need a source and which actions need review. A budget limits permitted spending; it does not establish answer quality. A successful model response also does not prove that an external action completed. Check the resulting record or connected service and make the outcome understandable to the person responsible for it.

Which data and processing decisions belong in the brief?

List the records the app stores, who owns them and which services receive them. Chromoly's application database uses PostgreSQL on Supabase in Ireland. EU AI mode uses the configured Berget AI route. Global processing, a customer-supplied provider key and connected external services have their own locations and terms. Choosing an EU database does not establish where every email, payment or external API request is processed.

Review sensitive fields, member permissions, retention needs and the process for correcting or removing records. Separate public website content from private operational information. An integration should have a named account owner and only the access required for its task. Before launch, document which provider handles each step and who can reconnect an expired account. These decisions make the system easier to operate and give your team a clearer basis for its own privacy and security review.

Decide which information belongs in a structured field and which belongs in a document. A due date, owner and status should usually be searchable as fields; a long project brief may be better kept as supporting material. Record the source of imported information and agree how duplicates will be handled. If a team is moving from a spreadsheet, first review a small synthetic sample of the intended mapping. Resolve ambiguous column names and missing identifiers before anyone relies on the imported records.

How do you improve an app without losing control of changes?

Describe the intended result of a change and inspect the draft before publication. A new field may affect a form, a table, an agent instruction and a report. A renamed status may affect filters or scheduled work. Dependency information supports that review, but it does not replace tests of the workflows people rely on. Agree how existing records should behave when a change introduces a new requirement.

Martin Fowler's explanation of refactoring is a useful engineering reference for this discussion. Ask your delivery team how it will keep a change small enough to review, preserve the behavior that should remain and test the parts that intentionally change. In Chromoly, customer publication approval can be required for an exact saved version. Further edits need another review when that rule applies. Keep the publication decision separate from accepting an initial brief or approving a design.

Treat changes to stored information differently from changes to appearance. Adjusting spacing is not the same task as changing a field type or making an existing optional value mandatory. Ask how old records will be handled, which reports depend on the field and how the result will be checked. Where the change needs migration or recovery work, agree that work before publication. Keep a clear record of the version being reviewed so that feedback about an earlier draft is not mistaken for approval of a later one.

Which edge cases should you test before publication?

Test the main journey and the ways it can fail. Submit an incomplete form, try a duplicate record, use a member account with fewer permissions and open the app on a narrow screen. Check navigation between pages, date and currency formatting, empty states and readable validation messages. For integrations, test an expired connection and an unavailable service as well as the successful response.

A generated preview can use real records and connected services. Use synthetic records, destinations you control and accounts with suitable permissions. Sending a test message or submitting a live form can still have a real effect. Include checks for repeated clicks and retries so that the intended workflow does not create duplicate actions. Agree the acceptance examples before launch, record what was tested and make any remaining limitations visible to the person deciding whether to publish.

What should happen after the app goes live?

Name the people responsible for app changes, connected accounts, incidents and customer communication. Agree the support scope, capacity assumptions and how a problem should be reported. Keep the first onboarding focused on the tasks people perform: creating a record, finding an assigned item, correcting a mistake and requesting help. Feedback from those real tasks is more useful than asking whether the app looks finished.

Jakob Nielsen's usability principle below is a useful review criterion. A member should be able to tell whether a record was saved, an action is still running or something needs attention. Clear status messages and an understandable recovery route matter after launch as much as they do in a prototype. Bring a short list of recurring problems to the next improvement cycle, agree which changes matter most and review the next draft against the same practical acceptance examples.

Prepare a short operational handoff. It should identify the owner of each connected service, the people who can publish, the expected support route and the information to include when reporting a problem. Agree retention, export and recovery needs for the workload rather than assuming they follow from hosting alone. Before replacing an existing process, decide how the team will handle work already in progress and what it will do if the new connection is temporarily unavailable. Review those responsibilities when the workflow or delivery team changes.