CepatEdge

Appearance

Why CepatEdge Exists ​

CepatEdge is not a “modern SaaS starter” or a demo of edge buzzwords. It exists because maintenance and facilities tooling is dominated by a small set of CMME-style vendors who sell slow products, wrap them in beautiful decks, charge brutal recurring licenses, and lock institutions into ecosystems that are painful to leave.

If you have sat through a vendor demo and felt the product was built for procurement committees — not for the people doing the work — you already understand the problem.

The real problem is power, not features ​

On paper, many of these systems “work”: tickets, history, reports. The issue is not the basic feature list. The issue is who has power:

  • Vendors design for renewals and upsells, not for simplicity.
  • Institutions get trapped in multi-year contracts where changing tools is politically and technically expensive.
  • Innovation moves at the pace of roadmaps and sales cycles, not the people who run maintenance and operations.

Universities, hospitals, and public agencies end up paying serious money for systems that are slow, hard to integrate with anything the internal tech team controls, and take months of negotiation to change a field, a workflow, or a report.

CepatEdge is built to move that power back toward the team that runs the institution — and the small dev team that supports them.

Freedom first: own your stack ​

The core principle is simple: you should be able to run a serious maintenance platform on infrastructure you control, at a cost that feels almost trivial compared to the value it provides.

That means:

  • Open, understandable architecture — TypeScript, edge workers, a standard Postgres database, and patterns you can reason about.
  • No secret “magic” SaaS backend — the logic you rely on lives in your repo, in code you can audit and change.
  • Swappable pieces — if you outgrow a provider (database, auth, hosting), the architecture is shaped so you can move without rewriting your whole life.
  • A tree and ADRs that tell the story — each part has a job; decisions explain why, not just what.

“Swappable pieces” is not marketing. The system is deliberately shaped so a developer who has never seen the codebase can get oriented in a couple of weeks, not months — even with a large backend surface. The architecture, ADRs, and folder structure exist to make it clear where to look, how to swap providers, and why decisions can be trusted.

This is not anti-cloud. It is anti-captive. You should evolve your stack on your terms, not on a vendor’s billing calendar.

Cost efficiency: serious capability, trivial cost ​

Most institutions do not fail because they cannot scale technically. They fail because the commercial model makes scaling painful.

CepatEdge is engineered so that:

  • You can serve a serious institutional workload on free/low tiers of modern infra.
  • You pay for commodity resources (CPU, storage, bandwidth), not per-seat licenses or “enterprise add-ons”.
  • You can demonstrate real, production-grade value before anyone signs a scary contract.

In practice:

  • Edge workers keep traffic close to users — performance that feels expensive when the infra is not.
  • Aggressive caching and careful database usage avoid burning money on pointless queries.
  • File storage and delivery sit on cheap, CDN-backed systems instead of “enterprise content modules” with hidden line items.
  • The backend treats the database as something you mostly touch on writes, not reads: cache-first paths, write-driven invalidation, role-aware payloads.

The biggest silent bill in most “enterprise” tools is database spam: every screen re-fetches the same data; every dashboard is a query explosion. Under normal usage, the goal is that the DB is touched mostly on writes — so infra serves real work, not the same answer a thousand times a day.

Roles, permissions, and honest UI ​

A lot of systems have “roles” on a slide, then scatter if-statements across frontend and backend. CepatEdge tries to be disciplined:

  • The backend knows who you are, what you can do, and enforces that in one coherent model.
  • The frontend does not guess permissions; it asks the backend, then shapes the UI around what is actually allowed.
  • The same model flows into routing, buttons, and visibility — if you cannot perform an action, you should not see a shiny button inviting you to try.

Employees, technicians, department heads, and administrators each see a system that matches their reality. The point is not only security. It is clarity and trust — one source of truth for developers, and a UI that seems to “just know” what a user can do.

Built under pressure — on purpose ​

CepatEdge is also personal. This codebase was not produced by a giant vendor team with a hundred engineers and a decade of legacy. It was put together by a 19-year-old, in first year of university (semester 3), around Feb–Apr 2026, with final exams looming and real life pressure from all sides.

Most people would be told to slow down and not overreach. This project comes from the opposite instinct: lean into discomfort.

  • Take on architecture that feels a bit too big.
  • Learn edge infra, caching, security, and domain modeling at once.
  • Ship something that could actually run a real institution’s maintenance — not just a demo.

If there is one thing this repo tries to prove, it is that with pressure, clear goals, and a willingness to be uncomfortable, a single focused person at 19 can build something that stands next to what giant vendors ship — with more honesty and more respect for the people who will depend on it.

The goal is not “free forever at any scale”. The goal is that when you finally pay serious money, it is because you are genuinely successful — not because you crossed an arbitrary pricing threshold.

A different kind of enterprise ​

CepatEdge still takes enterprise needs seriously:

  • Auditing, security, and role-based access are first-class.
  • The architecture is documented enough for security and IT reviews.
  • The system is designed for real-world responsibilities, not hobby projects.

It rejects the idea that “enterprise” automatically means closed source, opaque pricing, custom sales calls for basic features, and long contracts for mediocre performance.

Instead, it aims to be a platform you can fork, run, and extend internally; adapt to your institution’s quirks without begging a vendor; and inspect from top to bottom so security and infra teams are comfortable.

Who this is really for ​

This project is for:

  • Institutions that want serious maintenance and operations tooling without ceding total control to external vendors.
  • Small, sharp dev teams inside those institutions who will own a modern stack but do not want to invent everything from scratch.
  • People on the ground (technicians, staff, HODs) who want the system fast, predictable, and out of the way.

If you want a glossy, fully-managed black box where every new field is a “change request” and every report is an upsell, this is not that.

If you want to understand and own the thing that runs a big part of your operations — and keep your infra bill sane — this is exactly for you.

How to read the repo with that lens ​

  • The root README.md gives the technical shape.
  • The docs site (docs.cepatedge.com, source under docs/ + apps/docs/index.md) covers architecture, operations, and institutional story.
  • This page is the philosophy — the refusal to play the usual enterprise SaaS game.

You can agree or disagree with the opinions here. The important part is: they are explicit. You are not buying into a black box. You are picking up a tool, with a clear stance, meant to put power and cost control back in your hands.