Synthetic Sample: Software Rescue Assessment.
Fictional example. Northstar Field Services, the DispatchDesk application, all people, numbers, systems, incidents, and findings in this document are invented to demonstrate the format of a Codepoet assessment. This is not a real client engagement, testimonial, or claim about past results.
Client: Northstar Field Services (fictional)
Application: DispatchDesk (fictional)
Prepared by: Brian Brackeen, Codepoet LLC
Assessment window: August 3–12, 2026
Report date: August 14, 2026
Confidentiality: Public synthetic sample
Executive Verdict.
DispatchDesk does not need an immediate rewrite. Its core scheduling model is understandable, the senior developer is capable, and the application can continue serving the business while targeted changes are made.
The immediate problem is delivery control. Work enters through three channels, nobody owns the final priority, releases depend on one person, and urgent requests regularly interrupt unfinished work. Two authorization flaws and an untested restore procedure create risks that should be corrected now, but neither requires replacing the complete system.
Recommendation: stabilize the current application for 60 days, correct the access-control and recovery risks, establish one owner for priorities, and decide on the reporting-module refactor after delivery data is visible. Do not add developers during the first 30 days.
Decisions Needed From the Owner.
- Name the COO as the single business priority owner by August 18.
- Approve a two-week pause on new reporting features while authorization and restore work is completed.
- Require the current vendor to demonstrate a database restore in a non-production environment by August 28.
Condition Summary.
| Area | Condition | Business Effect | Confidence |
|---|---|---|---|
| Product and scope | Yellow | Competing priorities interrupt completion | High |
| Code and architecture | Yellow | Reporting changes are slow and risky | Medium |
| Security and data | Red | Two roles can reach records outside their intended region | High |
| Deployment and reliability | Yellow | Release and rollback knowledge is concentrated in one person | High |
| Delivery process | Red | Work is started faster than it is finished | High |
| Team and vendor accountability | Yellow | Roles are capable but authority is unclear | Medium |
| Documentation and ownership | Yellow | Runbooks are incomplete | High |
Scope and Evidence.
Reviewed one Laravel web application, its React dispatch console, two repositories, the primary PostgreSQL schema, GitHub pull-request history for the prior six months, 412 issue-tracker records, staging deployment configuration, and interviews with the owner, COO, operations manager, vendor lead, senior developer, and QA contractor.
Production credentials were not requested. Codepoet received read-only repository and issue-tracker access and a sanitized staging database. The assessment did not test the production network, payment provider, employee devices, or the third-party GPS platform.
What Is Working.
- The scheduling domain model is coherent and covered by focused unit tests.
- The senior developer could explain the important data flows and identified the same reporting risk found in the code review.
- Staging deployments are automated and use versioned database migrations.
- Customer support records show no pattern of lost work orders during the reviewed period.
- The business has a clear reason for keeping DispatchDesk: it encodes routing and service rules that are not available in the company’s off-the-shelf CRM.
Prioritized Risk Register.
| ID | Priority | Risk | Evidence | Business Effect | Recommended Action | Owner | Timing |
|---|---|---|---|---|---|---|---|
| R-001 | High | Region filters are absent from two manager export paths | Route/controller review and staging reproduction | A manager could export another region’s customer records | Add policy enforcement and regression tests | Vendor lead | Now |
| R-002 | High | Database backups exist, but no restore has been demonstrated | Cloud configuration and interviews | Recovery time and data integrity are unknown | Restore latest backup into isolated staging and document results | Vendor lead | Now |
| R-003 | High | Three people independently change the sprint priority | Issue history and interviews | Work is repeatedly interrupted and misses commitments | Establish one priority owner and one intake queue | COO | Now |
| R-004 | Medium | Reporting queries duplicate business rules across 14 files | Static code review | Changes are slow and introduce inconsistent totals | Extract shared reporting service after stabilization | Senior developer | 31–60 days |
| R-005 | Medium | Production releases and rollback depend on one developer | Deployment records and interviews | Absence or departure could delay urgent releases | Pair on two releases and write a short runbook | Vendor lead | 31–60 days |
R-001: Manager Exports Do Not Enforce Region Ownership.
What was observed
The normal customer-list query applies the signed-in manager’s region. The CSV export and saved-report export load records by submitted account identifiers without applying the same policy. The behavior was reproduced in staging using two fictional regions.
Why it matters
A manager who changes an export request could retrieve customer names, addresses, and service history belonging to another region. No evidence was found that this occurred in production. Production logs were outside the assessment scope, so past exploitation is unknown.
Recommended response
Apply the existing region policy inside both export query paths, add tests that submit out-of-region account identifiers, and review the previous 90 days of export logs if those logs exist.
Confidence and limits
High confidence in the staging behavior and code path. No production exploitation claim is made.
Delivery and Team Assessment.
The team is not obviously understaffed. Its largest constraint is conflicting authority. The owner, COO, and operations manager each add urgent work directly to developers. The issue tracker contained 37 items started but not completed, and 11 of the prior 14 planned items moved into a later cycle.
The current vendor reports hours and ticket activity but does not give the owner a short account of commitments, completions, carryover, and decisions needed. Meetings average 7.5 person-hours per week across the delivery group, yet priority conflicts remain unresolved.
Required Role Changes.
| Decision | Current Owner | Needed Owner | Change |
|---|---|---|---|
| Business priority | Owner, COO, and operations manager | COO | All requests enter one queue; COO orders the queue |
| Architecture | Senior developer, informally | Senior developer with owner visibility | Record material decisions in pull requests |
| Release approval | Senior developer | QA verifies; COO approves business timing | Separate technical readiness from business timing |
| Vendor performance | Owner | COO | Review commitments and completions every two weeks |
Options and Tradeoffs.
| Option | Benefits | Main Risk | Planning Cost Band | Planning Time Band |
|---|---|---|---|---|
| Stabilize current system | Fastest reduction of immediate risk; preserves working domain logic | Reporting work remains slower until refactored | $35,000–$55,000 | 8–12 weeks |
| Targeted reporting refactor after stabilization | Reduces repeated business rules and makes later changes safer | Requires disciplined scope and comparison testing | Additional $25,000–$45,000 | Additional 6–10 weeks |
| Full rebuild now | New technical foundation | High migration cost; delays security/process fixes; discards working knowledge | $240,000–$400,000 | 9–15 months |
These fictional ranges illustrate planning bands, not bids or typical Codepoet pricing.
30/60/90-Day Recovery Plan.
First 30 Days.
- Correct R-001 and verify the fixes with automated tests.
- Demonstrate and document a backup restore in isolated staging.
- Name the COO as the sole business priority owner.
- Stop starting new reporting features until the current four are completed or explicitly cancelled.
- Replace the weekly status meeting with a 30-minute decision meeting using commitments, completions, carryover, risks, and owner decisions.
Days 31–60.
- Pair a second developer on deployment and rollback twice.
- Create a one-page release and rollback runbook.
- Measure planned items completed, carryover, work in progress, and release frequency for four cycles.
- Design the shared reporting service and write comparison tests against the current totals.
Days 61–90.
- Decide whether delivery data supports beginning the reporting refactor.
- Move the first two reports behind the shared service if approved.
- Review the vendor’s role, capacity, and commercial structure using eight weeks of delivery evidence.
- Decide whether ongoing Fractional CTO oversight is still needed.
Do Not Do Yet.
- Do not hire two additional developers. More people would increase coordination before priorities and ownership are corrected.
- Do not begin a full rewrite. The evidence does not justify its cost or migration risk.
- Do not replace the senior developer. The assessment found useful system knowledge and sound judgment in the areas reviewed.
Measures for the Owner.
| Measure | Baseline | 30-Day Target | 90-Day Target |
|---|---|---|---|
| Planned items completed in cycle | 3 of 14 | At least 70% | At least 80% |
| Work in progress | 37 items | Under 15 | Under 10 |
| Production releases | Irregular; 1 in prior 6 weeks | 1 safe release every 2 weeks | Maintain useful cadence |
| People able to perform release and rollback | 1 | 2 paired | 2 independently verified |
| High-priority open risks | 3 | 0 | 0 |
Final Owner Note.
The project has recoverable software and capable people. The owner’s best next investment is not a rewrite or a larger team. It is a short period of risk correction and unambiguous control over priorities. At the end of 60 days, the company should have enough delivery evidence to decide whether the reporting refactor and current vendor arrangement deserve further funding.
Reminder: every fact above is fictional. This synthetic sample exists only to show the structure, directness, evidence boundaries, and decision focus of a Codepoet Software Rescue Assessment.