Engineering / Research & Development
1. Overview & Mandate
Business Unit Purpose Engineering / R&D is responsible for the design, development, operation, and evolution of the MorgueBoard® SaaS platform. This unit ensures the platform is reliable, secure, scalable, and maintainable, while translating approved product requirements into production-ready systems.
Mandate Statement Engineering / R&D exists to deliver high-quality technical execution in service of the product roadmap, customer commitments, compliance requirements, and long-term platform viability.
Primary Accountability Owner
- Primary: Engineering Lead (Dom Bavetta)
- Supporting: Product Management, Technical Compliance & Security, Operations
2. Core Functions & Responsibilities
Core Functions
- Application development (frontend, backend, APIs)
- System architecture and technical design
- Infrastructure, DevOps, and deployment pipelines
- Quality assurance and testing
- Performance, scalability, and reliability engineering
- Technical debt management
- Engineering documentation and internal tooling
Explicit Responsibilities
- Build features and enhancements approved via Product Management
- Maintain platform uptime, performance, and data integrity
- Ensure engineering practices align with security and compliance standards
- Own technical implementation decisions and delivery timelines
- Identify and remediate architectural risk and technical debt
- Support implementations and escalations where technical changes are required
Explicit Non-Responsibilities
- Product roadmap ownership
- Customer contractual commitments
- Clinical or institutional compliance interpretation
- Sales timelines or scope negotiation
3. Decision Rights & Authority Boundaries
Important Context The decision rights and boundaries outlined in this section are intentionally high-level and directional. They are designed to provide clarity at a business unit level, not to serve as the authoritative or exhaustive policy governing decision-making. Detailed, binding decision authority, escalation paths, and governance mechanisms are formally defined in the company’s Decision Rights & Governance Policy.
This section should be interpreted as a summary aligned with those governing documents; in the event of conflict, the formal decision rights policy prevails.
Engineering Owns Decisions Regarding:
- Technical architecture and design patterns
- Tooling, frameworks, and infrastructure choices
- Implementation approaches and sequencing
- Release readiness from a technical perspective
Engineering Does Not Own:
- Feature prioritization (Product Management)
- Security and compliance policy definition (Technical Compliance, Privacy & Security)
- Go-live commitments (Implementation / Professional Services)
- Budget ceilings (Executive / Corporate Leadership and Finance & Accounting)
Escalation Triggers:
- Technical constraints that materially impact product or customer commitments
- Conflicts between delivery timelines and security or compliance requirements
- Customer-specific requests that introduce platform divergence or sustainability risk
4. Key Interfaces & Dependencies
| Interface | Nature of Interaction |
|---|---|
| Product Management | Requirements intake, feasibility validation, tradeoff discussion |
| Technical Compliance, Privacy & Security | Security controls, audit readiness, risk remediation |
| Implementation / Professional Services | Technical enablement, integrations, configuration support |
| Operations | Tooling, documentation, internal reliability |
| Customer Success & Support | Escalations, defect resolution, stability issues |
5. Budget Ownership & Cost Structure
Engineering Budget Scope
- Engineering labor (internal, contractors, fractional resources)
- Infrastructure and hosting costs
- Development tools, licenses, CI/CD tooling
- Monitoring, logging, and observability tools
- Security tooling as required for engineering execution
Budget Ownership Model
- Engineering manages spend within an approved budget envelope
- Executive Leadership and Finance approve annual budgets and material incremental spend
- Engineering provides forward-looking cost forecasts tied to roadmap delivery and scale assumptions
6. General KPIs & Performance Metrics
Delivery & Execution
- Feature delivery predictability
- Release cadence consistency
- Escaped defects per release
Platform Health
- Platform uptime and availability
- Mean time to resolution (MTTR)
- Performance benchmarks (response time, throughput)
Engineering Quality
- Test coverage trends
- Size and age of technical debt backlog
- Rework and regression rate
Security & Compliance Support
- Volume of vulnerability findings identified vs. remediated
- Time to remediate security and penetration test findings
- Audit and compliance remediation timelines
7. Initiatives & Goals Tracking
| Initiative / Goal | Description | Owner | Success Criteria | KPI(s) | Target Date | Status | Notes |
|---|---|---|---|---|---|---|---|
| Complete Azure V2 Production Environment & Migration | Finalize configuration of the Microsoft Azure V2 production environment, migrate all existing services, and decommission the legacy production environment to reduce hosting costs and align with enterprise-grade security expectations. | Engineering | All production services running exclusively in V2; legacy environment fully decommissioned | Hosting cost reduction, service stability, migration defect rate | Q4 2026 | Planned | Requires focused allocation of engineering capacity and coordinated cutover planning |
| Establish Security Monitoring & Vulnerability Management Function | Engage a fractional engineer responsible for continuous monitoring, triage, mitigation, and documentation of vulnerability scans, penetration testing findings, and security reporting. | Engineering | Continuous vulnerability monitoring in place with documented remediation workflows | Time to remediate findings, open vs. closed vulnerabilities | Q2 2026 | Planned | Role is fractional and security-focused, not feature delivery |
| Build and Operationalize QA / Test Program | Design and implement a formal QA and testing program, including test strategy, tooling, and ongoing execution to support MorgueBoard® development. | Engineering | QA framework established and actively used across releases | Test coverage, escaped defect rate | Q3 2026 | Planned | Fractional QA-focused engineering resource required |
| Develop & Operationalize Internal Support Tooling | Add engineering capacity (fractional or project-based) to design, build, and maintain internal tools that enable Customer Success/Support and Operations (e.g., support dashboards, internal admin tools, workflow automation). | Engineering | Internal tooling actively used by dependent business units with measurable efficiency gains | Support resolution time, operational task automation rate | Q4 2026 | Planned | Scope and prioritization coordinated with Customer Success and Operations |
| Deployments without downtime (A/B slots) | |||||||
| Centralization of LLM markdown standards (style guide, coding principals, etc.) |
8. Maturity Roadmap
Current State Founder-led execution with limited specialization, constrained by finite engineering capacity and competing priorities.
Next State Augmented engineering function with fractional specialists supporting security, QA, and internal tooling, improved delivery reliability, and reduced single-point dependency.
Future State More formally layered engineering organization with redundancy, mature testing and security practices, robust internal enablement tooling, and clear separation between feature development, reliability, and compliance support.
9. Document Revision History
This table tracks material changes to this Business Unit Charter to ensure transparency, continuity, and governance as the organization evolves.
| Version | Date | Description of Change | Author | Approved By | Approval Date |
|---|---|---|---|---|---|
| 1.0 | 2026-01-04 | Document Creation | Nic Bavetta |