Owned productUltra Hi-End audio
DoMiSoul
Presents tube amplifiers, private listening sessions, and personal audio-system setup.
- Current status
- Operating
- Author’s role
- Founder and engineer
Product task
Connect a physical engineering product, a private service model, and a commercial digital path without substituting website claims for audio-system performance.
Author’s role
I founded DoMiSoul and take responsibility for connecting the physical product, engineering practice, positioning, and its operating digital path.
Decisions that mattered
These are not technology badges. Each choice closes a concrete product or operating constraint.
nginx and a minimal PHP 8.3-FPM in a dedicated pool
- Constraint or risk
- DoMiSoul is a light PHP application with shared templates and a contact form, and one managed VPS serves several small products.
- Why this choice
- A dedicated pool and its own release path keep runtime, publication, and data logically separated between products on a shared origin; images are published as AVIF, WebP, and JPEG without a separate runtime service.
Separate the physical product areas, editorial journal, and contact path
- Constraint or risk
- The digital presentation needs to explain amplifiers, tuning, and listening sessions without attributing physical-product functions to the website.
- Why this choice
- Visitors can distinguish the product areas and see where public content ends and personal engineering work begins.
Immutable release, checksum verification, and an atomic switch
- Constraint or risk
- Uploading files in place could leave production in a mixed or incomplete state.
- Why this choice
- A new file set is verified separately before the active link switches as one operation; the previous release remains available for rollback.
Keep form data outside the web root and deliver notifications through the existing mail path
- Constraint or risk
- The site needs durable request capture and reliable email without moving mail hosting.
- Why this choice
- Requests are stored outside releases and the web root and closed to direct access, while notifications are sent through the existing mailbox over authenticated SMTP; DNS and mail stay where rational.
What the facts establish
Connects the commercial presentation of a real product with an operating digital system.
Fact → evidence → boundary
Evidence record
18 pages connect products, the journal and enquiries
- Evidence
- The register covers the home page, product areas, contact, legal pages and six journal articles.
- Boundary
- The website establishes digital presentation. Sound quality and amplifier performance require separate verification.
Enquiries are stored independently of website releases
- Evidence
- Each enquiry receives an identifier and is stored outside the replaceable website directory; notifications use a persistent retry queue.
- Boundary
- A queue does not guarantee every email will arrive. The 20 September record confirms a control delivery on that date.
A verified file set is switched as one release
- Evidence
- The new directory is checked before switching; the previous release remains available for recovery.
- Boundary
- This manages change without promising the absence of all failures.
The date belongs to the source record. Reading it is not a new check of the operating system.
Verify it yourself
Public verification boundary. The public site lets a visitor inspect the areas of work, journal, listening sessions, and contact path. A web page cannot prove amplifier performance or the result of private tuning, and this case does not pretend otherwise.