Case Study 03 · Work completed at Alpaca Systems
Rebuilding field operations software around an ERP migration
A stalled product rebuild spanning field tickets, rentals, inventory, invoicing, dashboards, and a hard-deadline ERP migration.
Outcome
Delivered the migration on time and established a maintainable foundation for field, rental, inventory, shipping, and invoicing workflows.
Role and context
What I owned
- Formal title
- Web Developer, later Full-Stack Developer
- Project responsibility
- Solo owner, then primary engineer and mentor for the rebuilt application.
- Team context
- Initially a solo engineering assignment; later paired with a junior developer and coordinated with project, QA, deployment, and client stakeholders.
- Personally owned
- Rebuild architecture, core application implementation, ERP integration API, workflow delivery, technical estimates, releases, and mentoring.
- Collaborator ownership
- Stakeholders supplied operational priorities; QA and deployment contributors supported release confidence; the junior developer implemented scoped work with guidance.
The operational problem
Software had to match the way the work moved.
A stalled field-ticketing system needed a dependable rebuild while a client moved from a legacy ERP to a modern cloud ERP on a hard deadline.
Constraints that mattered
- Requirements changed repeatedly while the ERP transition date remained fixed.
- Operational workflows crossed field entry, rentals, inventory, shipping, accounting, and reporting.
- The application had to preserve delivery momentum while replacing an unsuccessful earlier implementation.
Integration
API boundary
Cloud ERP
Business Central
Diagnosis
Find the system behind the symptom.
- 01
Mapped which system owned each business record and where synchronization had to be explicit.
- 02
Separated reusable ERP operations from client-specific workflow behavior.
- 03
Used delivery risk and dependency order to turn an unstable request list into staged scope.
Decision log
The choices and their costs.
01
Build an ERP boundary
Created a reusable Business Central integration API for common synchronization and translation concerns.
Trade-off
The extra service boundary added operational responsibility, but contained vendor-specific behavior and reduced duplication.
02
Organize around operational flows
Built rentals, inventory, transfers, shipping, invoicing, and dashboards as connected workflows rather than isolated screens.
Trade-off
Cross-flow consistency required careful ownership rules and more stakeholder clarification.
03
Use scope as a technical control
Translated late changes into estimates, dependencies, and staged delivery choices while keeping the migration deadline visible.
Trade-off
Some desirable refinements followed the critical migration work instead of entering the deadline path.
What changed
Result and evidence
- The rebuilt application supported the ERP transition by the required deadline.
- Field and office workflows shared a clearer integration foundation.
- The project expanded from solo ownership to guided contribution without implying formal people management.
Evidence quality
The deadline and delivered workflow scope are supported by the career record. Reuse and business impact are described qualitatively without internal adoption counts.
Reflection
What I would improve today
I would now put integration contracts, idempotency expectations, failure handling, and migration rehearsal into a visible delivery plan earlier, especially when scope volatility and a fixed external date intersect.
This Case Study is a sanitized account of work completed at Alpaca Systems. Product and client names are withheld. Visuals are original conceptual explanations using invented data; no former-employer screenshots, source code, schemas, or proprietary diagrams are shown.