jstanbul / Engineering handbook
Our way of making decisions, technical choices and responsibilities visible from the first conversation to life after launch.
A good digital experience does not end at a beautiful screen. The right problem, a clear interface and a dependable system are parts of the same decision.
Understand the need
We discuss your business, your audience and what a visitor came to do. We review the existing site, content and technical dependencies. Success is more than appearance: discoverability, comprehension, conversion and maintainability belong in the brief. We do not call a promise we cannot measure a success criterion.
Reduce uncertainty
Pages, content, integrations, deliverables, revisions and timing are explicit in the proposal. We do not assume an unreviewed data source or API will work. First-year maintenance, domain, hosting and model usage costs are kept distinct. If a new request changes cost or timing, we discuss its impact before doing the extra work.
Build the system
Information architecture, hierarchy, typography, colour, states and screen sizes are designed together. Form errors, longer copy and missing images are design problems too. Motion should explain a decision or give feedback; content never waits for an animation to finish. One shared decision list keeps feedback, design and development aligned.
Make it a product
We build reusable interface components with semantic HTML and accessible interactions from the start. Where content management is needed, we define who updates which data and how. Server operations validate input and communicate failure clearly. For AI or 3D work, we verify data, device and integration constraints before choosing the technology.
Check the work
We review desktop and phone layouts, keyboard use, focus order, forms and failure states. We check reduced-motion preferences, image loading, both languages and links. This site's development gate includes TypeScript, ESLint, translation checks, automated tests and a build; project-specific browser scenarios cover critical journeys as well.
Hand it over
Before launch we review the domain, environment variables, deployment access, analytics consent and a recovery path. We verify content and forms in production. We explain who owns each account and piece of content, what maintenance covers and how new features are handled. Third-party subscriptions are shown separately from the project fee.
From the printed handbook / Technology and process
Tools and reasons
We do not apply one fixed stack to every client. The tools below are used on this site or scoped for a suitable project; each choice starts with the need, the data and the target devices.
React components keep repeated decisions consistent; Next.js supports page delivery, routes and metadata. Semantic HTML, responsive images and bilingual content make the experience clearer for people and search engines.
React · Next.js · TypeScript · next-intl
CSS handles short state changes. GSAP coordinates more involved sequences. The content and actions remain available when motion is turned off.
CSS · GSAP · reduced motion
Content management, forms and persistent records follow the actual workflow. Server routes on this site validate input; Supabase stores some persistent data. A CMS or another service is selected only after the data and permissions are clear.
Server routes · validation · Supabase
We turn a real place into a browser scene using Gaussian splatting. Capture planning, scene cleanup, device performance and information points are part of the experience. Essential information and actions remain available if the scene cannot load.
Gaussian splatting · capture · fallback view
Assistants, search and recommendations should connect intent to real data. We limit data access and tool permissions and design for poor answers and unavailable services. The interior example on this site shows prepared concepts; it does not generate live model output.
Ready data · bounded access · clear failure state
Build, testing, release and observation form one delivery chain. This site uses Vercel for deployment and performance signals; analytics depends on user consent. For another project, infrastructure follows access, cost and maintenance needs.
Vercel · tests · consent-based analytics
Quality gates
Meaningful structure, readable contrast, keyboard access, visible focus and a motion alternative are baseline checks.
We review image size, loading order and unnecessary client code. Real device behaviour informs the decision.
Types, lint, translations, tests and build are checked. Critical user journeys are tried in a browser.
Access, dependencies, content updates and deployment responsibilities should be clear at delivery.
Transparency
Timing, integrations and maintenance vary by project. Before discovery, we do not promise a specific performance outcome, an unverified API connection or unlimited revisions. We write down decisions and additional costs before work starts.