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 who coordinate daily tasks for a loved one or client. Families benefit from clearer schedules, proof of completion, and a shared record that reduces miscommunication. The result is less stress for caregivers and more accountability for the people they support.
For property managers, strata councils, and residents who are tired of missed announcements and maintenance requests disappearing into email chains. Communities benefit from one shared place for announcements, requests, documents, and decisions. The impact is fewer repeated questions, faster maintenance resolution, and a clear record of what was communicated.
For people with disabilities, caregivers, and accessibility advocates who need to know whether a restaurant, clinic, park, or transit stop will work for them before they travel. Municipalities and businesses benefit from crowdsourced accessibility data that shows where improvements are needed. The impact is safer, more confident trips and better public awareness of accessibility gaps.
For website owners, developers, and accessibility teams who need a quick, actionable first look at accessibility barriers. Small businesses and non-profits benefit from prioritized fixes instead of overwhelming scanner reports. The impact is faster remediation and a site that works for more visitors, including people using screen readers or keyboards.
For business owners, marketers, and web teams who want to turn more visitors into leads or customers. Small businesses benefit from practical fixes to headlines, calls to action, and page structure without hiring a full conversion agency. The impact is clearer messaging, better user flow, and more revenue from the same traffic.
For churches, ministries, and faith-led teams that need a website visitors can actually use, including people with disabilities or older members. Congregations and visitors benefit from clear event information, simple donation flows, and accessible content. The impact is stronger community connection and fewer people left out because a site is hard to navigate.
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.