CASE STUDYEngineering & Manufacturing

LIVEEngineering Business Digital Platform · India

Gravion Engineering

One platform for an industrial engineering business: public site, customer portal and back-office CMS.

Gravion Engineering provides industrial engineering services, engineering trading and supply support to customers across India. KAPAT engineered a single platform that presents the business publicly, gives customers a portal for enquiries, RFQs, quotations, work orders and documents, and lets the company run its catalogue and content from one administration system.

Public WebsiteCustomer PortalAdmin CMSRFQ WorkflowLaravel APIReact

Project interface

Client: Gravion Engineering
Project Type: Digital platform: website + portal + CMS
Industry: Industrial engineering services & supply
Platform: Web (responsive), API-first
Engagement: Architecture, engineering, release preparation
Status: Live
Live: gravion.net.in

Business Context

An engineering supplier whose customers expect structure, not just a brochure.

Gravion Engineering serves industrial customers who buy engineering services and supplied components through a formal commercial cycle: an enquiry becomes a request for quotation, a quotation becomes a work order or project, and documents, invoices and service requests follow. A brochure website could describe the company, but it could not carry that cycle.

The brief was therefore a platform rather than a site: a credible public presence with a searchable catalogue of services, products and industries; a customer portal in which each customer organisation sees only its own commercial records; and an administration system from which the company publishes content, manages the catalogue and works the commercial pipeline.

The Challenge

Three audiences — the public, customer organisations and internal staff — on one system, with strict separation between what each may see and do.

Organisation-scoped access

Portal users belong to customer organisations. Every enquiry, RFQ, quotation, work order, invoice and document had to be visible only within the organisation that owns it, enforced on the server rather than in the browser.

Server-enforced roles

Internal users needed differentiated permissions across commercial, catalogue, website and governance functions — with the rules living in the API, not in front-end toggles.

Content and catalogue as data

Pages, navigation, footer, services, products, industries and portfolio items had to be managed and published from the CMS with draft and published states, instead of being hard-coded.

Shared hosting constraints

The client's hosting is a shared Apache and MariaDB environment. Queues, scheduling, file handling and deployment had to be designed for what that environment can actually run.

Documents and media safely

Commercial documents and website media are uploaded by different users for different purposes. Uploads had to be scanned, gated by eligibility rules and served privately or publicly as appropriate.

Prototype to production

The certified React front-end existed first as a prototype with demonstration data. It had to be retained visually while every record, permission and workflow became real, API-driven behaviour.

Requirements

Requirements taken from the business and the prototype.

The certified React prototype existed first, with demonstration data. The engagement audited it, confirmed the business facts and defined what every record, permission and workflow had to do before the API and data model were built.

Business

Enquiry → RFQ → quotation → work order / project lifecycle
Service requests and support tickets
Invoices and payment references
Catalogue of services, products and industries

User Experience

Public site with search and RFQ basket
Portal dashboard, lists and record detail views
Admin shells for commercial, catalogue, website and governance work
Responsive across desktop, tablet and mobile

Security

Session-based SPA authentication
Role-based access with resource-level gates
Organisation isolation for portal data
Throttled password reset; safe redirect handling

Content Management

Pages with versions and blocks
Menus and footer groups
SEO metadata per page
Draft / published lifecycle for catalogue items

Documents & Media

Private commercial documents with controlled download
Public website media with eligibility rules
Malware scanning before acceptance
PDF generation for commercial records

Operations

Audit log and login activity
Notifications and delivery logs
Database-driven queue and scheduled jobs
Deployment package for shared hosting

KAPAT Approach

How KAPAT approached the work.

01
Discover
Audited the certified prototype, confirmed business facts and identified every prototype-only behaviour.
02
Architect
Planned the Laravel API, MySQL data model, auth model and hosting-aware queue and file strategy before implementation.
03
Model
Defined the schema: organisations, memberships, commercial records, catalogue, CMS, media, audit — with a shared status vocabulary.
04
Engineer
Built the versioned API by module — public, portal, admin — and connected the React shells to it, replacing demonstration data.
05
Certify
Automated browser certification of public, portal and admin surfaces across six viewport widths, plus backend and front-end test suites.
06
Harden
Local release audit: fixed access, upload and redirect findings with regression tests; verified bundle size and type safety.
07
Package
Produced the hosting deployment package, database bootstrap, secure admin bootstrap and rollback procedure.

System Architecture

How the system is structured.

Single operating company, many customer organisations. Same-origin React application over a versioned Laravel API.

L6CLIENTS
Public websiteCustomer portalAdmin CMSReact 19 · Vite · Tailwind
L5API
/api/v1/public/api/v1/portal/api/v1/adminLaravel · Sanctum SPA sessions
L4DOMAIN
Organisations & membershipsEnquiries · RFQs · QuotationsWork orders · Projects · InvoicesCatalogue · Pages · Media
L3CONTROL
Roles & permissionsResource policiesAudit logRate limiting
L2SERVICES
Database queueSchedulerMalware scan gatePDF generationNotifications
L1PLATFORM
Apache shared hostingMariaDB / MySQL 8Private + public storageDeployment package

What Was Engineered

What was engineered.

Public website

Home, about, services, products, industries, projects, capabilities, quality, downloads, careers, contact, RFQ and service-request pages, search, sitemap and legal pages — content served from the CMS.

Catalogue & RFQ basket

Published-only public APIs for product categories, products, services, industries and portfolio, with a basket that carries selected products into a portal RFQ.

Customer portal

Authenticated, organisation-scoped views of enquiries, RFQs, quotations, work orders, projects, service requests, invoices, documents, notifications, support, contacts, account and security.

Admin CMS

Commercial pipeline, catalogue management with draft/publish, website pages with versions and blocks, menus, footer, SEO metadata, settings and governance screens.

Access control

Sanctum SPA cookie sessions, separate portal and admin user kinds, server-side roles and permissions, resource-level gates such as internal-note access.

Media & documents

Upload pipeline with malware-scan gating, public-readiness rules for website media, private commercial documents with controlled download, PDF output for records.

Operations layer

Audit logging, login activity, notifications with delivery logs, database queue with scheduler, idempotency keys and health snapshots.

Quality & certification

Backend PHPUnit suite, front-end Vitest suite and Playwright certification runs with ephemeral credentials against isolated integration databases.

Release package

Verified database export with checksums, hosting deployment guide, secure super-admin bootstrap command and documented rollback.

Engineering Facts · from the project repository

API surface: Versioned REST · public / portal / admin (327 routes)
Tests at release audit: 325 backend PHPUnit · 80 front-end Vitest · Playwright certification
Access model: 11 roles · 38 permissions · organisation scoping
Type safety: TypeScript strict — 0 errors; largest chunk under 400 kB

Engineering Decisions

Decisions, and the reasoning behind them.

Single-company platform, not multi-tenant SaaS

The business operates as one company with many customer organisations. Modelling organisations and memberships — rather than tenants — kept the data model honest and the permission rules simpler to reason about.

Retain the certified front-end, replace its foundations

The React shells had already been certified visually. Keeping them and swapping demonstration state for API-driven state preserved design investment while removing every prototype-only behaviour from production.

Session cookies over API tokens

With the browser as the only client, Sanctum SPA cookie sessions avoided token storage in the browser. Token issuance was deferred until a non-browser client is actually approved.

Design for shared hosting, upgrade later

Database-driven queues and cron scheduling were chosen as the safe default because they run on the target hosting. Redis or persistent workers remain an upgrade path, not a prerequisite.

Fail closed on uploads

The release audit found paths where an unscanned or failed-scan file could still be accepted. Those paths now reject and delete the object, with regression tests to keep it that way.

No demonstration data reaches production

Demonstration organisations and records were confined to isolated integration databases and guarded seeders. The production export ships with zero rows in every customer and commercial table.

Interface

Selected interface views.

Verified screenshots only. Frames marked in preparation are replaced as screenshots are approved for publication.

Gravion customer portal sign-in (captured from the platform build)

Gravion public website — capabilities page (captured from the platform build)

What KAPAT Handled

KAPAT's contribution.

Requirements & architectureData model & API designReact front-end integrationLaravel API engineeringAccess control & security hardeningMedia & document pipelineAutomated certificationRelease packaging & deployment guide

Outcome

Outcome statements are published only once verified with the client. Detailed engineering documentation for this project is being prepared for publication.

Need a system built with this level of care?

Start with the business problem. KAPAT will define the architecture, the scope and the engineering approach with you.

Discuss Your Project

A direct conversation with the engineers who would build the system — no sales layer in between.

View Services