Development Process

This is a rough outline of the process we should always follow for developing and publishing new features for the portal and automations. Please note that for larger projects, some phases are repeated until the project is complete.

Terms

There are a few terms used here that need to be understood in the context.

Phase: A phase indicates a segment of work that is completed together. A phase is typically completed 100% before moving on to the next phase.
Milestone: A milestone is a key checkpoint in development that marks a meaningful shift in focus. Milestones group related phases into a broader, easier-to-track scope. Although phases are listed under each milestone, a milestone is considered reached once all of its phases are complete.
Key Players: Key players are the stakeholders who have interest in the success of the project. This typically includes managers of end users, end users themselves, and other impacted teams. We determine who to involve in scoping and approval based on the impact of the project.

Responsibilities

The primary developer is responsible for:

Writing, or at least thoroughly understanding and owning the scope
Creating sketches
Drafting the architecture plan
All development
Ensuring development does not go outside of scope

Managers are responsible for ensuring:

Research meetings are scheduled at convenient times for key players
All relevant key players are involved in scoping and approval
The scope and timeline are realistic and attainable
Approval is given at each required phase before moving on
Trevor and Jeff stay informed throughout the progress and are given the opportunity to provide feedback
The final product meets the needs of end users
Follow-ups are completed after rollout

Milestone 1: Scope and Architect

Phase 1: Scope

Research
- Meet with key players to determine problem statements and scope. Start with the highest level manager that is directly impacted, and ask if any other managers or end users should be consulted.
- Use other software team members to help collect problem statements.
Write the scope
- Define objectives that are measurable, realistic, and tied to an attainable deadline.
- Outline what belongs in the MVP and what can be deferred to the final release.
  MVP boundaries should be drafted here and finalized in the architecture step.
- Remove or table unrealistic ideas.
Manager approval
- Review scope with your supervisor.
- Confirm the proposed deadline is attainable.
Jeff's approval
Jeff's approval may be skipped for routine development (such as automations), at the blue-level manager's discretion. However, in those cases Jeff must still be @ mentioned on the final version of the scope for review.
Outside approval
- Approval by key players
- Give Trevor Klotz a copy of the approved scope. We do not require his approval, but he needs to be kept in the loop.

Phase 2a: Sketch

Create sketches: Produce quick sketches for each screen or component. Full wireframes are usually too detailed and take a lot of time to create.
tldraw is a great tool for sketching!
Get approval: First get approval from your manager, then from Jeff.
Outside approval is not required.

Phase 2b: Architect

Draft architecture plan
- Build quick POCs for areas where implementation will be challenging or is confusing, and plan to discard them after learning.
- Scope the MVP precisely.
- Draft a short list of alpha/beta testers if you expect to need testing.
Get approval: First get approval from your manager, then from Jeff.
As with scopes, architecture for routine development doesn't need to be approved by Jeff, but Jeff still needs to be notified and given a chance to provide feedback.
Outside approval is not required.

Milestone 2: MVP / Beta Release

Phase 3: Develop MVP

(if applicable) Build the basic app
- Create a repository
- Set up a hosting site
- Configure the domain
- Set up CI/CD
- Set up branch protection rules
- Build the core of the app
- Get through PR review
For each screen or functional area, do the following:
1. Service / repo: implement the needed service and repository layer(s).
2. UI: build the use cases and UI.
3. Approval: get approval through PR review.
The idea here is to break up the work into many small chunks. This helps to speed up the approval process (with smaller PRs), and keeps the feedback channels open throughout development.
Test the MVP
- Run alpha tests with peers to prove workflows and iron out edge cases.
- (as needed) Beta testing with end users as soon as features are developed.

Milestone 3: Final Release

Phase 4a: Final Development

Build out any features not included in MVP.

Phase 4b: UI / UX Review

Internal review
- personal testing by developer
- alpha testing with peers
- testing and review by supervisor
- testing and review by Jeff

Phase 5: Release

Demo and review
- Get final approval from your supervisor.
- Get final approval from Jeff.
- Review and demo functionality with key players.
Publish the app
(as needed) Beta/gamma testing with end users
- Use a small group to find unclear workflows or UI.
- Fix blocking bugs and incorporate critical feedback.

Milestone 4: Rollout

Phase 6: Training and Follow-ups

Record a release demo video and send it to Jeff for dissemination.
Train end users
- Provide 1:1 training for initial users, then create documentation and training materials for future users.
Follow up and monitor
- Check in regularly for 3-6 weeks to ensure smooth operation and fix any issues.
- Prioritize bug fixes above other development during this period.
  After this period is complete, bug fixes resume normal impact-based prioritization.

Phase 7: Retrospective

Retrospective and rollout wrap-up
- Review what went well and what to improve for the next cycle.
- Document lessons learned and adjust playbooks for future development.

15 December 2025