Skip to engineering evidence
INDEX / 2026FOUR PROJECT FAMILIES

Make the work
inspectable.

Real architecture decisions, trade-offs and checked-in source references. A fast, readable alternative to the cinematic portfolio — without invented benchmarks or production claims.

04PROJECT RECORDS12DOCUMENTED DECISIONS
4 projects / 12 matching decisions
01 / ENGINEERING RECORD

GARTAL

Digital studio and independently versioned business platform

The GARTAL studio website is not the GARTAL product runtime.

Read full case study ↗
01EXPERIENCE

How should a potential client discover the right service?

Implemented / documented approach

Distinct Next.js App Router service paths, localized content and a Zod-validated, database-backed project-inquiry API.

Engineering trade-off

A purpose-built marketing layer is simpler to explain but must remain separate from transactional applications.

Why this is in the portfolio

The current studio README and lead API source document multilingual service routes, validation, PostgreSQL persistence, administrative review and privacy controls.

02ARCHITECTURE

How can multiple vertical products reuse infrastructure without merging runtimes?

Implemented / documented approach

Cross-product manifests and versioned industry packs coordinate four separately owned application runtimes.

Engineering trade-off

Contracts reduce duplicated definitions but require deliberate cross-repository compatibility checks.

Why this is in the portfolio

The platform README defines Core Server, Core Admin, tenant store, Super Admin and the pack verification workflow.

03DELIVERY

Which parts are source-defined versus actually released?

Implemented / documented approach

Keep local code checks, brand/SEO review, authorization and public indexing as separate release gates.

Engineering trade-off

A conservative launch policy adds review steps but avoids confusing a GitHub commit with a live site.

Why this is in the portfolio

GARTAL-SITE README explicitly requires approval before production domain configuration and indexing.

Project overview

Read a concise explanation of the documented architecture without opening repository files.

ENGINEERING OVERVIEW

GARTAL

GARTAL combines a distinct web and software services studio with a separate multi-repository business platform. The main studio website communicates website design, custom development and automation; the platform coordinates reusable product foundations.

THE PROBLEM

Businesses need a clear route from service discovery to project inquiry, while product teams need shared contracts instead of repeatedly building the same operational foundations.

THE IMPLEMENTATION

The GARTAL studio site now uses Next.js App Router, React, TypeScript and multilingual service pages, with a validated project-intake API backed by PostgreSQL and Drizzle. The separate GARTAL Platform versions shared contracts for independent admin, server and commerce runtimes.

VERIFIED SCOPE

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.

KEY DECISIONS

  • Distinct Next.js App Router service paths, localized content and a Zod-validated, database-backed project-inquiry API.
  • Cross-product manifests and versioned industry packs coordinate four separately owned application runtimes.
  • Keep local code checks, brand/SEO review, authorization and public indexing as separate release gates.
WEBSITE / COMING SOON
02 / ENGINEERING RECORD

AI Development Factory

GitHub-to-local owner engineering control

A GitHub revision, a locally installed Worker and a verified delivery are three different facts.

Read full case study ↗
01ARCHITECTURE

How can one owner coordinate several repositories?

Implemented / documented approach

Use GitHub as source truth and a single authorized Windows Worker for the local checkout boundary.

Engineering trade-off

Central ownership simplifies provenance but requires knowing which Worker revision is actually installed.

Why this is in the portfolio

The current README specifies one local Owner Worker and active-project monitoring.

02DELIVERY

What happens if GitHub changes but the local repository has owner edits?

Implemented / documented approach

Guarded fast-forward fetch/pull is permitted only within the Worker's safe synchronization policy.

Engineering trade-off

Preserving an unresolved checkout is safer than destructive resets, at the cost of delayed synchronization.

Why this is in the portfolio

The current policy explicitly requires preservation of local edits and separates remote state from installed state.

03EXPERIENCE

How should engineering quality be represented without claiming checks that never ran?

Implemented / documented approach

Present plugin evidence with source identifiers and states such as missing, stale or explicitly reported.

Engineering trade-off

Evidence can be incomplete, but an honest NOT_TESTED is more useful than a fabricated pass.

Why this is in the portfolio

The Guardian contract treats report files as evidence handoffs, not independently verified release gates.

Project overview

Read a concise explanation of the documented architecture without opening repository files.

ENGINEERING OVERVIEW

AI Development Factory

A multi-repository engineering control center linking GitHub commits, a single local Windows Worker, protected fast-forward synchronization, project lifecycle controls and source-anchored Guardian Hub evidence.

THE PROBLEM

A growing portfolio of repositories needs a repeatable way to inspect source changes and preserve local work, without treating an unverified status as a successful delivery.

THE IMPLEMENTATION

Use GitHub as the source of truth and an owner-operated local Worker for active-project HEAD monitoring, safe source synchronization and a loopback-only control dashboard. Guardian reports remain evidence-based and tied to immutable Git metadata.

VERIFIED SCOPE

The current October 2026 source policy disables automatic CI, build, tests and preview inside the Worker. Source updates are not proof of an installed release; the dashboard distinguishes actual machine state from unverified claims.

KEY DECISIONS

  • Use GitHub as source truth and a single authorized Windows Worker for the local checkout boundary.
  • Guarded fast-forward fetch/pull is permitted only within the Worker's safe synchronization policy.
  • Present plugin evidence with source identifiers and states such as missing, stale or explicitly reported.
WEBSITE / COMING SOON
03 / ENGINEERING RECORD

DigiRezhim

Clinical nutrition application with physician and administrative boundaries

The software supports clinical workflows without representing source code as medical certification.

Read full case study ↗
01ARCHITECTURE

Why separate the public product from administrative operations?

Implemented / documented approach

The repository documents dedicated public/admin web and API runtimes with PostgreSQL, Prisma and Redis.

Engineering trade-off

Clear responsibility boundaries introduce operational coordination between services.

Why this is in the portfolio

README and project scripts describe independently started web/admin surfaces and API services.

02EXPERIENCE

How do physicians see reliable rather than invented account or patient states?

Implemented / documented approach

Use authenticated server-backed doctor profile, verification, subscription and patient records.

Engineering trade-off

State can be unavailable or restricted; honest error and access feedback takes precedence over decorative metrics.

Why this is in the portfolio

The checked-in doctor dashboard reads profile/verification/subscription state and protected patient-list data.

03DELIVERY

How do spreadsheet-derived scientific rules move into software?

Implemented / documented approach

Document rule/form migration, source acceptance and explicit scientific exceptions instead of executing workbooks in production.

Engineering trade-off

The migration process needs scientific review separate from routine code or UI acceptance.

Why this is in the portfolio

The README links to nutrition-engine migration records and notes that current production readiness is not CI-verified.

Project overview

Read a concise explanation of the documented architecture without opening repository files.

ENGINEERING OVERVIEW

DigiRezhim

DigiRezhim connects public web surfaces, doctor workspaces, dedicated admin services and structured clinical nutrition records across a four-surface application architecture.

THE PROBLEM

Nutrition and clinical follow-up work spans intake, patient history, scientific rules, physician review and access management. Disconnected tooling makes these processes difficult to coordinate.

THE IMPLEMENTATION

A Next.js physician workspace backed by NestJS APIs, structured PostgreSQL data and Redis. Doctor dashboard source handles medical registration, profile readiness, account access, patient lists and clinical-workflow entry points.

VERIFIED SCOPE

The repository documents a clinical nutrition system, an Excel-to-UI migration and physician administration workflows. Production readiness and clinical compliance are not presented as independently certified.

KEY DECISIONS

  • The repository documents dedicated public/admin web and API runtimes with PostgreSQL, Prisma and Redis.
  • Use authenticated server-backed doctor profile, verification, subscription and patient records.
  • Document rule/form migration, source acceptance and explicit scientific exceptions instead of executing workbooks in production.
VISIT LIVE WEBSITE ↗
04 / ENGINEERING RECORD

Petiwoo

Species-aware pet commerce on a shared product family

Product discoverability begins with the animal and its needs rather than a generic stock image grid.

Read full case study ↗
01EXPERIENCE

How do shoppers navigate different animal product needs?

Implemented / documented approach

Species-aware browsing, category hierarchy, product search and promotional catalog discovery.

Engineering trade-off

More specific navigation depends on consistent taxonomy and inventory data.

Why this is in the portfolio

The storefront README and homepage source identify product and category retrieval paths.

02ARCHITECTURE

How does the storefront connect selection with commerce operations?

Implemented / documented approach

Typed product pages, client basket state and backend catalog/order interfaces are separate concerns.

Engineering trade-off

Local cart persistence improves continuity but must not be mistaken for server-confirmed payment or order creation.

Why this is in the portfolio

The repository documents Zustand cart state, product retrieval and checkout pathways.

03DELIVERY

What can Petiwoo reuse from GARTAL?

Implemented / documented approach

The platform describes petshop and veterinary versioned industry packs rather than cloning shared runtimes.

Engineering trade-off

Pack releases require compatibility checks across independently versioned product repositories.

Why this is in the portfolio

The shared-platform README lists the pack and verification workflow.

Project overview

Read a concise explanation of the documented architecture without opening repository files.

ENGINEERING OVERVIEW

Petiwoo

Petiwoo is a pet-focused commerce experience. The storefront source includes product discovery by species and category, promotional offers, stock-aware product presentation, brands, basket and checkout.

THE PROBLEM

Different animal needs and inventory conditions make a generic product catalog difficult to navigate, while store operations require accurate stock and pricing context.

THE IMPLEMENTATION

Build a Next.js TypeScript storefront with category-tree navigation, search, species-based discovery and a cart, connected to shared catalog and commerce services in the GARTAL family.

VERIFIED SCOPE

Repository source confirms storefront pages, product transformation, categories, brand feeds, inventory context and cart/checkout pathways. Illustrative sales figures or fabricated pet product records are deliberately excluded.

KEY DECISIONS

  • Species-aware browsing, category hierarchy, product search and promotional catalog discovery.
  • Typed product pages, client basket state and backend catalog/order interfaces are separate concerns.
  • The platform describes petshop and veterinary versioned industry packs rather than cloning shared runtimes.
VISIT LIVE WEBSITE ↗