This page documents the content rules, architecture, project evidence, quality checks, APIs, deployment model, and repository documentation behind danspelt.com.
Standards
These rules keep the site credible, accessible, and maintainable as the project portfolio grows.
Completed portfolio work is promoted only when it has a public product, a case study, or another verifiable proof point. Marketing language stays subordinate to evidence.
Semantic structure, keyboard access, readable contrast, descriptive links, and screen-reader-friendly content are treated as baseline requirements.
Case studies explain the operational problem, constraints, implementation decisions, outcomes, and tradeoffs rather than only listing technologies.
The site favors durable static pages, shared data sources, explicit status labels, and conservative claims that remain accurate as projects evolve.
Content model
The site separates completed proof-backed work from the broader product inventory so visitors see a clear, trustworthy portfolio.
The `/work` page is curated. Apps appear there only when they are deployed and have a public case study or equivalent project proof.
`/projects` is the full product inventory. It can show deployed applications and in-development builds without implying that every tool is a finished case study.
Open project inventoryCase studies document the problem, approach, decisions, outcomes, evidence, and stack. They are the canonical proof layer for completed portfolio work.
Open case studiesInventory
A concise register of product names, current status, and public destinations. This inventory is broader than the curated completed-work list.
Built for household managers and approved care workers coordinating daily tasks. Combines schedules, proof of completion, and a shared record, with the aim of clearer coordination and accountability. Reduced stress and miscommunication have not been measured.
For property managers, strata councils, and residents coordinating announcements, requests, documents, and decisions. One shared system is designed to reduce repeated questions and improve maintenance follow-up; those benefits are not yet supported by published measurements.
For people with disabilities, caregivers, and accessibility advocates checking a place before travelling. Structured checklists, labelled scores, photos, and reports make accessibility information available to inspect. Safer trips and improved awareness are intended benefits, not measured results.
A demo app for BC property and strata managers. Sends formal notices to residents digitally, records resident consent (date and method such as the RTB-51 form), blocks residents who have not consented, and tracks delivery per recipient (sent, delivered, opened, acknowledged). Each notice gets a timestamped proof-of-delivery log with a SHA-256 content fingerprint and CSV/JSON audit export.
Architecture
The site is intentionally simple to operate: static-first content, shared data sources, a small API surface, and a repeatable deployment path.
Experience
Each audience has a different evidence need. The site structure supports fast scanning first and deeper verification second.
About → Employment history → Case studies → Contact
Evaluates experience depth, evidence quality, accessibility practice, and role fit.
Home → Custom software → Work → Contact
Understands the business problems solved, product approach, and inquiry path.
Case studies → Documentation → GitHub → Projects
Inspects architecture, tradeoffs, verification, source material, and shipped scope.
API surface
The public site remains mostly static. API routes are limited to integrations, form delivery, diagnostics, and assistant features.
/api/healthDeployment and service health check endpoint.
/api/projectsProject data for site features and integrations.
/api/githubGitHub repository data used by portfolio content.
/api/emailTransactional email through the configured mail provider.
/api/custom-software-inquiryCustom software inquiry submissions and notification delivery.
/api/business-challengeBusiness challenge summaries and optional contact submissions.
/api/ai-chatPortfolio assistant responses grounded in approved site data.
/api/ai-chat/emailFollow-up delivery for qualified assistant conversations.
/api/github-testDiagnostic endpoint for validating GitHub integration configuration.
Quality
Verification is lightweight but explicit. The goal is to catch content, accessibility, build, and integration regressions before deployment.
Repository
The repository contains the operational source of truth. These documents support setup, deployment, project status, and future maintenance.
Setup, development commands, deployment summary, and repository orientation.
Current site status, milestones, known issues, and resume checklist.
Latest session handoff, portfolio rules, verification results, and pending local work.
Docker, environment, hosting, and production deployment notes.
Operational guidance for the portfolio and sibling applications.
Product planning
Developer guides document product scope, architecture, implementation boundaries, and deployment considerations for planned or sibling applications.
Operations
The operating model is designed for a solo maintainer: clear source data, deterministic builds, environment-based configuration, and push-to-deploy infrastructure.
Feature work is reviewed through Git history. Main should remain deployable, and unrelated local changes should not be bundled into focused fixes.
Changes are verified locally, pushed to main, and deployed by Coolify using the standalone Docker build.
Project status, dependency alerts, accessibility, metadata, and public claims should be reviewed as the portfolio evolves.