Engineering
How I build software
The principles I work by, each paired with where I've actually applied it. Most examples come from SignalTechRepairSystem, which is in pilot preparation — so each section also says what isn't done yet.
This page describes my engineering practice. It is not a security certification or a guarantee that any system is free of defects.
Architecture
Keep the moving parts few and the boundaries clear: a typed frontend, an API that owns the business rules, and a relational database that enforces what it can.
In practice
- React and TypeScript frontend served as static files; a Node.js/Express API is the only path to data.
- PostgreSQL schema changes ship as ordered, rerunnable migrations, separate from first-time setup.
- New client businesses are created by an operator command-line tool rather than a public sign-up form.
Not yet / limits
- Designed and documented for a single-server pilot; it has not been run as a multi-instance deployment.
Validation and business rules
Rules that matter to the business live on the server, are written down explicitly, and are backed by database constraints where possible.
In practice
- Repair status changes follow one explicit transition map; any change not in the map is rejected.
- A repair cannot be sent for customer approval before a diagnosis is recorded.
- Final quality checks must record pass, fail or not tested for nine device functions; the database rejects any other shape.
- Request bodies are validated against explicit schemas (Zod), size-limited and required to be JSON.
Data integrity
Money and stock must not be recorded twice or go missing because a network request was retried.
In practice
- Payments and sales accept an idempotency key, unique per tenant and stored with a fingerprint of the request. A retry returns the original result; a reused key with different details is rejected.
- Concurrent retries are handled with row locks inside a transaction.
- A repair payment larger than the outstanding balance is refused.
- Business changes are written to a tenant-scoped audit log, without passwords or tokens.
Testing
Test the rules that would be expensive to get wrong, against a real database, and say plainly what has and has not been verified.
In practice
- An integration test suite of 29 tests runs against a dedicated PostgreSQL test database.
- Tests cover cross-tenant isolation, session expiry, login throttling, every allowed and disallowed repair status change, quality-check gating, and payment and sale idempotency.
Deployment preparation
Write the runbook before the first deployment, including what must not be done.
In practice
- A staging and pilot runbook covers the server layout (HTTPS through nginx to a private API and database), least-privilege database roles, TLS, secret handling, migrations and client provisioning.
- The backend refuses to start without an explicit environment, and production configuration rejects wildcard CORS.
Not yet / limits
- Not yet deployed to production, and no pilot has been completed.
Tools I've used in verified work
Only technologies with confirmed use in a project are listed here.
Frontend
- React
- TypeScript
- Vite
- React Query
- React Hook Form
Backend and APIs
- Node.js
- Express
- Zod
Databases
- PostgreSQL
- SQL migrations
Security and quality
- Session hashing
- Rate limiting
- Audit logging
- Integration testing
Deployment
- nginx
- Linux / systemd (pilot runbook)
Documented for the pilot; not yet run in production.