Skip to main content
Dan Spelt

Selected work

Custom software development case studies

Two web platforms with different constraints: multi-tenant community software and civic accessibility data. Claims below are grounded in each project's implementation, tests, and technical documentation.

Filter case studies

Showing 3 case studies.

Pilot
Founder and sole developer

Community Hive

A shared communication and operations hub for property managers, strata councils, and residents. Communities stop losing announcements and maintenance requests in email chains, and everyone has a clear record of what was decided.

Problem

Property managers and community leaders coordinate buildings through email chains, paper notices, spreadsheets, and social media groups. Announcements are missed, maintenance concerns arrive through inconsistent channels, and there is no reliable record of what was communicated or decided.

Technical approach

One multi-tenant platform where each building has scoped data and each role sees only the information and actions it is permitted. Announcements, maintenance requests, documents, events, and polls share a single audit-friendly record.

Repository-backed evidence
  • Security and authorizationSession-based admin protection, route middleware, centralized council-role guards, tenant-scoped access, environment validation, and audit helpers are documented in the project production-readiness report.
  • TestingThe repository includes Jest unit and integration coverage, a separate E2E configuration, smoke tests, and documented daily and release verification workflows.
  • Operational evidenceDocker configurations cover development and production, while migration, billing, legal-review, QA, and production-environment checklists document the path from development to operation.
  • Product evidenceThe case study includes captured property-manager, council, resident, messaging, security-camera, and business-promotion screens from the product.
Read the case study
Active
Founder and sole developer

CareBoard

A private care-coordination platform for household employers and approved care workers. Managers assign and track work; workers see only their own tasks; schedules, proof photos, handoffs, and an audit log keep everyone accountable.

Problem

In British Columbia, people who self-manage their care — including CSIL household employers — are legally the employer. They are responsible for scheduling, task assignment, timesheets, and employment records, while their care workers need predictable shifts, clear instructions, and safe ways to report concerns. Most of that coordination still happens through group chats, paper notes, and memory.

Technical approach

A private household task board with strict role separation. A manager creates, assigns, and completes work and maintains employer records; each worker sees only their own tasks and open work they can claim. Shifts follow a two-week A/B cycle, and proof photos, end-of-shift handoffs, safety reports, and an append-only audit log make accountability routine rather than extra effort.

Repository-backed evidence
  • Security and role isolationWorkers cannot see other workers' profiles, tasks, reports, or audit data. Disabled workers are blocked on every request, so an existing session cannot retain access. Photos are served only through authenticated, ownership-checked routes.
  • Privacy by defaultProfile and task proof photos are retained for a fixed 90-day period and are never exposed as static files.
  • TestingThe repository defines a required verification suite of Node.js tests, lint, and a production build, run before any change is considered complete.
  • Known constraintRuns on SQLite in a single container, sized for one household per deployment. Payroll CSVs provide hours, rate, and gross amounts — deductions and net pay remain payroll-software scope, documented in the CSIL readiness matrix.
Read the case study
Active
Founder and developer

AccessLens

Built for people with disabilities, caregivers, and accessibility advocates who need reliable accessibility information before visiting a new place. Civic organizations and businesses gain visibility into where accessibility is working and where it needs to improve.

Problem

People with disabilities cannot tell in advance whether a restaurant, park, clinic, or transit stop will actually work for them. Accessibility information is inconsistent, unverified, or missing entirely.

Technical approach

Crowdsourced accessibility reports scored across ten criteria and rendered as colour-coded markers on an OpenStreetMap map, so a place can be assessed before travelling to it.

Repository-backed evidence
  • Accessibility evidenceAccessibility is the product data model, not a decorative claim: places record entrance, door, elevator, washroom, parking, signage, transit, aisle, and service-animal information alongside photos and issue reports.
  • Security and validationAuth.js supports Google, magic-link, and credential sign-in. Reviewer and business capabilities are enforced in API routes and UI, with Zod schemas covering runtime input validation.
  • TestingVitest covers accessibility scoring, validation, and badge thresholds; Playwright provides an end-to-end smoke suite. A Docker test workflow is also documented.
  • Known constraintPhoto uploads currently use local filesystem storage, and business subscriptions use a pending placeholder state until billing is connected. Both limitations are called out in the README.
Read the case study