GARTAL
One foundation. Multiple businesses.
A digital studio and a product platform, related in philosophy but separate in implementation.
A client inquiry is not a product platform.
The studio needs service-specific pages and a reliable way to receive project briefs. The separate product platform needs shared contracts without forcing independent applications into a single runtime.
- Client task: choose a service and send a brief
- Engineering task: avoid duplicating product contracts
Next.js intake. Versioned product contracts.
GARTAL-SITE uses Next.js service routes and a validated lead API with PostgreSQL and Drizzle. Gartal-Platform separately defines contracts for administration, servers, commerce and industry packs.
- Zod validation on project requests
- Separate admin, server and storefront boundaries
Source exists. Launch results need proof.
The repositories contain service routes, inquiry handling and industry-pack descriptors. A production launch, paying customers or completed cross-product integration cannot be concluded from source files alone.
- Evidence: GARTAL-SITE and Gartal-Platform repositories
- Status: implementation documented; deployment not certified
Behind the decisions.
Explore the implementation context, technical trade-offs and evidence behind the three-part story. Open any chapter to read the full explanation.
0101 / CONTEXTTwo systems. One engineering philosophy.
GARTAL has two distinct software identities. Its studio website introduces website design, ecommerce, custom software, interface design and business automation. A separate multi-repository platform coordinates shared contracts for independent business applications.
The distinction matters. A marketing and project-inquiry website is not a tenant administration dashboard. They serve different users, have different technical boundaries and should be assessed on their own terms.
For this case study, the visual language follows the real studio brand while the systems narrative explains how the platform supports reusable product foundations.
- Service-facing digital studio
- Separate shared-platform engineering
- Evidence from both repositories
0202 / THE PROBLEMA clear front door. A reusable engine.
Clients evaluating digital services need a direct path from understanding an offer to describing a project. Ambiguous navigation, generic claims or invented success metrics weaken that process rather than improve it.
On the product side, disconnected apps can independently recreate authentication, administration, product records, tenant boundaries and operations. Duplicated foundations raise the cost of maintaining industry-specific products.
The engineering problem is to create clarity at the service layer without coupling unrelated runtime products into one fragile application.
- Explicit service discovery
- Permission-aware project requests
- Independent runtimes
0303 / THE STUDIO WEBSITEA focused client journey.
The current GARTAL-SITE main branch is a Next.js App Router application using React and TypeScript. It retains service-specific content for website design, ecommerce, custom development, automation and project inquiries, and now also defines localized public routes with language-specific metadata.
The Next.js source includes a Zod-validated project-intake endpoint, an administrative lead interface, PostgreSQL persistence through Drizzle, honeypot and same-origin checks, privacy content and canonical SEO metadata. If storage is unavailable, the intake endpoint returns HTTP 503 rather than claiming a request was saved.
The GARTAL repository documents an owner-approved upward-arrow brand mark and wordmark, superseding earlier orange/G explorations. This portfolio presents that work in its own neutral black-and-white system; a visual identity does not prove a released service or a customer result.
- Current Next.js App Router and multilingual public pages
- Validated PostgreSQL-backed inquiry intake
- Owner-approved current brand assets
0404 / SYSTEM ARCHITECTUREShared contracts. Separate applications.
The Gartal-Platform repository describes four independent runtime responsibilities: an API and persistence server, a shared administration interface, a tenant-facing storefront and a licensing or tenant-lifecycle control plane.
Its canonical industry-pack manifest gives domain-specific products a place to declare their capabilities and versions. Pet retail and veterinary workflows can evolve as specialized packs without copying an entire platform stack.
A shared architectural contract does not remove the need to validate each affected repository. The documented workflow requires changing canonical descriptors, bumping industry versions and checking impacted runtimes before a release decision.
- Core Server and Core Admin
- Storefront and Super Admin
- Versioned industry-pack contracts
0505 / INTERACTION DESIGNPurpose before ornament.
On the studio website, navigation follows actual client questions: what can be built, which problems fit, what a proposal involves and how a request is submitted. The interface is designed for direct answers rather than decorative claims.
Within the platform, operating dashboards separate products, orders, customers, stock, appointments and animal-related records. They reflect different tasks even when they reuse authentication and data contracts.
The resulting portfolio presentation uses written architectural evidence, not a fictitious administrator screenshot with fabricated revenue, customer counts or conversion figures.
- Sales-oriented information architecture
- Operational domain separation
- Accessible, responsive presentation
0606 / DELIVERY & EVIDENCEA documented foundation, not a fabricated success story.
The current Next.js source establishes service routes, localized metadata, protected lead-intake logic, brand definitions and platform contracts. This documents implementation, not a verified production rollout, client contract or business KPI.
Security gates, runtime checks, deployment templates and visual reviews are documented as work to complete or verify. They are engineering evidence, not a substitute for owner acceptance.
The next stage is to validate the deployed experiences, obtain permissioned screenshots and connect actual outcomes only when verifiable records exist.
- Repo-backed capabilities
- Deployment remains separately verified
- No invented commercial results
What is actually verified.
The checked-in studio website defines individual service routes, project intake, privacy and SEO metadata. The separate platform defines versioned industry-pack contracts. Neither a launched website nor customer results are claimed without acceptance evidence.
The overview explains documented implementation decisions. Production results and customer outcomes require separate verification.