Selected work
Steelabs resource library: from advice to working tools
Engagement at a glance
- Internal Website
- Software consulting
- 2026
- Steelabs — our own website
What happened
Challenge
The site explained engineering disciplines in detail, but readers had few concrete artifacts to take into their next release conversation. A contact selection omitted the AI service, resources were dispersed through reading pages and the audit example was an abbreviated preview. The practical task was to turn that advice into a usable journey: identify a gap, choose a worksheet, agree a first scope and send an inquiry with context the visitor can review.
Approach
We added a typed resource catalogue and downloadable Markdown, then built an eight-question readiness check and a transparent automation cost model. Search keeps the original article and glossary routes available while helping a reader narrow the library. A synthetic local shop gives the automation starter a reproducible buyer journey and negative API checks. The audit comparison separates worsened observations from changed coverage. Versioned brand files and workplace assets make the same identity usable outside the site.
Outcome
Visitors can inspect every worksheet before downloading, evaluate their stated readiness evidence locally, compare effort assumptions and carry a selected starting scope into the inquiry form. A permanent fictional audit demonstrates the report without requiring a live target. The starter packages include source, assertions and CI retention instructions. The links below expose the actual fixture execution record and implementation screenshots so the delivered behaviour can be reviewed directly.
Measurement context
This is an internal implementation record, not an anonymised client engagement. The first resource release passed 1,294 repository tests and audited 161 sitemap routes locally. The expanded starter subsequently passed four Playwright fixture tests and three mocked API-runner tests on 11 October 2026. Current full-release verification is recorded separately in the release evidence file. These checks do not establish revenue, conversion, production accessibility conformance or a speed improvement.
Why this stack
The existing Next.js, TypeScript and Tailwind stack already supported a typed publishing system, so the work extended it rather than introducing a CMS or another design framework. The interactive tools calculate in the browser and do not need a user database. Fresh script nonces require HTML to render per request; this security choice trades away static HTML caching while keeping fonts, scripts, images and downloadable artifacts cacheable.
What we would do differently
A content-rich site needs an artifact ownership process as much as more prose. ZIP downloads can drift from their source unless packaging is explicit, examples can be mistaken for client evidence unless their fictional status is prominent, and score comparisons can imply repairs when a crawler simply missed a page. Future releases should begin with the intended evidence format and retention choices, then build the interaction around those decisions.
Stack
- Next.js
- TypeScript
- Playwright
- Postman
- Allure
Contact
Something similar in flight?
Describe where it currently stands and what worries you about it. You will get a considered reply from an engineer, not an autoresponder.