Imagine building an event application with coding agents. A speaker uploads a new photograph. The portal shows a preview and a reassuring “Saved” message. An organizer opens the public conference agenda. The old photograph is still there.
The upload works. The public page works. They disagree about where the photograph belongs.
One development task covers the speaker portal, another the organizer dashboard, another the public website. Each implementation looks plausible in isolation. The upload writes an attachment to a user account; the public page reads a separate speaker profile. The connection between them was never defined.
For a technical lead, the question is how to organize development so that this mismatch becomes difficult to introduce and easy to detect. AI can make implementation faster. It also lets a team produce several incompatible interpretations of the product very quickly.
The conference application below is an illustrative design. I would approach it by defining the user outcome, agreeing on the contracts between features, and assigning someone responsibility for the complete journey.
Make the user outcome the unit of delivery
“Build photo upload” is too narrow to describe what the team needs. A useful delivery statement is: an authorized speaker replaces their event photograph, the organizer can review the change, and the approved version appears on the public agenda.
That statement immediately raises decisions hidden by the feature label. Does every upload go live automatically? Is the photograph global or specific to one event? Can an organizer change it? What should remain visible while a replacement is processing?
For this example, assume event-specific profiles and organizer-controlled publication. Those choices may be unnecessary for a small internal tool, but they are useful constraints for a conference with a public agenda.
Write the acceptance condition before splitting the implementation. Include the actor, starting state, action, downstream result and rule for declaring completion. Otherwise, each agent or engineer has to invent the missing product decisions independently.
A vertical slice is useful here: implement one photograph replacement all the way from speaker upload to public display. This exposes the data and publication boundaries before the team builds every portal. Parallel development can then use a contract that has survived an actual journey.
Agree on the records that connect the screens
I would give the event profile a stable identity shared by the portal, organizer tools and public view. An account identifies the person signing in. An event profile describes that person's public participation in a particular conference. These records have different lifetimes and responsibilities.
A compact contract might look like this:
| Record or boundary | Agreement for this application |
|---|---|
| Account | Identifies the signed-in person; does not own the event's public photograph |
| Event profile | Identified by event ID and profile ID; owns the current draft photo reference |
| Media asset | Has an asset ID and processing state; a stored file is not automatically publishable |
| Publication | Points to a reviewed profile revision, separate from the editable draft |
| Public agenda | Reads the published revision using the same event and profile identity |
The portal can display a temporary local preview, but it should distinguish that preview from a processed asset saved to the profile. The organizer sees the revision awaiting review. The public agenda reads the published revision. All three surfaces refer to the same underlying subject.
I would put these agreements in a short domain note and executable interface checks: identifiers, field meanings, allowed states and representative examples. A generated TypeScript type can prevent a field-name mismatch. It cannot decide whether photoId means a draft attachment or the publicly approved image. The examples need to establish that meaning.
For a small team, one application with shared domain modules and a relational database is a reasonable starting point. Independent services add deployment and consistency boundaries. They can be justified by existing infrastructure, team ownership or scaling needs, but dividing agent tasks is not itself a reason to distribute the runtime.
Model people with several roles
Now take a speaker who also represents a sponsor. A single role = speaker field may let them upload a photograph while blocking their sponsor tasks. Changing it to sponsor can break the speaker portal instead.
I would model event-scoped memberships separately from the account and allow the capabilities the person actually holds. The interface can offer a role switcher to keep work understandable. The backend must still check each action against the event, resource and membership; selecting a screen does not grant access.
For example, being a sponsor contact for one conference does not authorize editing another conference's public schedule. Being a speaker does not imply permission to approve one's own profile revision. These are product rules that need to survive every route into the application, including organizer tools and APIs.
Use the multi-role person early in acceptance testing. They reveal assumptions that separate “speaker” and “sponsor” demo accounts can hide. Also test removing one membership: the remaining duties should still work, while the removed capability should stop working.
Separate saved, reviewed and publicly visible
The photograph workflow needs more than a boolean called done. An upload can be received before processing finishes. A draft can be saved before review. An approved revision can exist before a public read model or cache reflects it.
In this design, the last published photograph remains visible while a replacement is processed and reviewed. A failed replacement leaves that published revision intact. The speaker sees the failure and a way to try again; the organizer sees which draft needs attention.
For a modest application, the public page can read the published record directly. That avoids a separate publication worker, although query cost and HTTP caching still need consideration. If the application serves a precomputed agenda, publication becomes a separate operation with a recorded target revision and visible progress.
An organizer approving revision 12 should not accidentally publish revision 13 uploaded during review. Bind approval and publication to a revision, and reject a stale change with a clear request to review again. A version check in the database write can enforce that rule for a single record. More complex cross-record rules need an appropriate transaction and concurrency strategy.
For an asynchronous public view, record both the requested revision and the last applied revision. Enforce a revision guard atomically when replacing the public reference, so that a delayed worker cannot overwrite a newer result; a separate check followed by a write leaves a race. If publishing fails, retry from the approved revision and show the operator that the public view is still behind. Do not ask the speaker to upload the photograph again to repair an unrelated publication failure.
The verification must include the actual public read path and relevant cache behaviour. A database query proving that a new value exists does not establish what an attendee sees. Choose and test the freshness promise the application can support; “eventually” needs a limit and an owner when that limit is exceeded.
Test the seams with several users and real state
Component tests are useful for image validation, membership checks and revision handling. Integration tests can establish that the portal writes a profile revision the publication path understands. A smaller set of end-to-end checks should connect those layers through the real application.
For the photograph journey, I would sign in as a speaker, upload a distinguishable image, review that exact revision as an organizer, and inspect the agenda in an unauthenticated session. Assert the event, profile and published revision as well as the rendered image. Seed the test through supported fixtures, then perform the workflow through the application rather than writing the expected result directly into the database.
The important cases reach across feature boundaries:
| Journey | Acceptance condition |
|---|---|
| Speaker replaces a published photograph | Existing image remains public until the replacement is approved; the approved revision then appears publicly |
| Processing fails | Draft shows a recoverable failure; the published image stays available |
| Speaker uploads again during review | A stale approval cannot publish the unreviewed replacement |
| Speaker also represents a sponsor | Both authorized workflows work without creating a second account |
| Sponsor membership is removed | Sponsor actions are rejected; speaker actions remain available |
| Organizer moves a session | The application rejects a room or speaker conflict, and the published agenda follows the agreed publication policy |
Scheduling deserves its own concurrency checks. Two organizers can both see a free room before either saves. A check in the browser cannot protect that rule. Enforce the scheduling invariant with suitable database constraints, locking or serializable transactions, and handle rejected or retried changes in the interface. The right implementation depends on the scheduling model.
An automated browser agent can help explore these flows and identify obvious breaks. I would keep explicit assertions for identity, authorization and state, then ask actual organizers to complete unfamiliar variations. A scripted test follows the team's assumptions; a user may reveal that invited speakers bypass the submission process entirely. That discovery changes the product contract, not merely the button label.
Give parallel work a shared integration owner
Once the first journey works, split tasks around stable interfaces. Each assignment should state which records it owns, which contract it consumes and which downstream result its checks must establish. If a contract changes, update its consumers together or provide an explicit transition.
Someone still needs to own the integrated result. That can be a technical lead or a product engineer working with the people who run the event. Their review includes unfinished transitions, duplicate records, permission gaps and misleading success messages across the application.
Before release, I would also agree who investigates a publication delay, where they can inspect the profile and revision, and how they recover without editing production records by hand. Record enough context to follow a change across boundaries: event, profile, revision and publication attempt. Keep the incident view scoped to authorized operators and avoid unnecessary personal data in logs.
Measure successful completion of the journeys that matter, including support interventions and publication delays. A large number of generated features or passing screenshots says little about whether organizers can prepare the next event.
What I would bring to the team
My work on Slivo connects a voice conversation, WooCommerce product data, visual selection and an order workflow. The SaaS backend also handles store isolation, usage and billing. Those are related responsibilities whose boundaries have to fit together. This conference design is a proposed approach, rather than a claim that I built an event-management platform.
For a team developing with AI, I would bring the same product engineering focus: define the records and state transitions, build a complete slice, make failure visible, and leave the next engineer an understandable system. The deliverables include the contracts, acceptance scenarios, integrated application and recovery guidance.
If you need an engineer to take responsibility for that work, tell me about your team and the role. Bring one user journey that crosses several features and a place where it currently breaks. That is a concrete starting point for discussing how I could contribute.