CepatEdge

Appearance

Why CepatEdge Exists ​

This project is not just another “modern SaaS starter” or a shiny demo of edge computing. It exists because the current maintenance-management and IT tooling ecosystem is dominated by a small set of CMME-style vendors who:

  • Sell slow, bloated products that everyone hates using.
  • Wrap them in beautiful slide decks and endless buzzwords.
  • Charge brutal, recurring license fees that grow every year.
  • Lock institutions into closed, fragile ecosystems that are painful to leave.

If you have ever sat through a vendor demo and felt like the product was built for procurement committees, not for the people actually doing the work, you already understand the problem CepatEdge is pushing against.

The Real Problem: Power, Not Features ​

On paper, a lot of these systems “work”: they track tickets, store history, and generate 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 a pace defined by roadmaps and sales cycles, not by the people who actually run maintenance and operations.

The result: universities, hospitals, and public agencies end up paying serious money for systems that:

  • Are slow and clunky.
  • Are hard to integrate with anything the internal tech team actually controls.
  • Take months of negotiation to change a field, a workflow, or a report.

CepatEdge is built to move that power back towards 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 simple 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 designed so you can move without rewriting your whole life.
  • A folder tree and ADRs that tell the story – instead of one giant ball of code, you get a tree where each part has a job, and ADRs that explain why it exists that way.

The “swappable pieces” part is not marketing: the system is deliberately shaped so that a developer who has never seen the codebase before can get oriented in a couple of weeks, not months, even with 250+ backend files (and growing). The architecture, the ADRs, and the folder structure are there to:

  • Make it clear where to look for a given concern (auth, users, maintenance, analytics, etc.).
  • Let you swap providers (DB, auth, storage) without ripping through the whole codebase.
  • Let a new maintainer trust the decisions because they can read the reasoning, not guess.

This is not about being “anti-cloud”. It’s about being anti-captive. You should be able to 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 technically scale; they fail because the commercial model makes scaling painful.

CepatEdge is intentionally engineered so that:

  • You can serve a serious university-scale 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 needs to sign a scary contract.

In practical terms:

  • Edge workers handle traffic close to users, making performance feel “expensive” even when the infra is not.
  • Aggressive caching and careful database usage mean you do not burn money on pointless queries.
  • File storage and delivery are pushed to 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: we cache aggressively and keep cache and DB in sync with smart invalidation and targeted refreshes.

The biggest silent bill in most “enterprise” tools is database spam: every screen re-fetches the same data, every action reloads entire hierarchies, every dashboard is a query explosion. CepatEdge is built around:

  • Role-aware, user-aware caching – cache what a given user/role actually needs, not random blobs.
  • Write-driven invalidation – when something changes, the cache knows exactly what to purge or refresh.
  • Cache-first reads – the normal path is cache → user; the DB is a quiet, respected source of truth.

When the cache misses, we hit the DB. But the goal is that under normal usage, the DB is touched mostly on writes, so your infra spends its time serving real work, not re-answering the same question a thousand times a day.

Roles, Permissions, and Frontend–Backend Alignment ​

A lot of systems have “roles” on a slide, but in practice everything is a messy set of if-statements scattered across frontend and backend. CepatEdge tries to be honest and disciplined here:

  • The backend knows who you are, what role(s) you have, and what you are allowed to do – and it enforces that in a single, coherent place.
  • The frontend does not guess permissions; it asks the backend and then shapes the UI around what the user can actually do.
  • The same permission model flows into routing, buttons, and visibility: if you cannot perform an action, you should not see a big shiny button inviting you to try.

That means:

  • Employees see only the actions and data that match their reality.
  • Technicians see what they need to execute work, not every Department Head or Administrator toggle.
  • Department Heads and Administrators get visibility and control, but they are still bound by the same permission model.

The point is not just “security”. It is clarity and trust – users see a system that seems to “just know” what they can do, and developers see one source of truth instead of ten.

A 19-Year-Old Under Pressure ​

CepatEdge is also personal. This codebase and architecture were not produced by a giant vendor team with a hundred engineers and a decade of legacy. They were 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 pressing from all sides.

Most people would be told to “slow down, focus on exams, don’t overreach”. But 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 all 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 – and do it 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 do 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.

But it rejects the idea that “enterprise” automatically means:

  • Closed source.
  • Opaque pricing.
  • Custom sales calls for basic features.
  • 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.
  • Inspect from top to bottom, so your 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 are willing to own a modern stack but don’t want to invent everything from scratch.
  • People on the ground (technicians, staff, HODs) who just want the system to be fast, predictable, and not get in the way.

If you are looking for a glossy, fully-managed black box where every new field is a “change request” and every report is an upsell opportunity, 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 This Repo With That Lens ​

If you are evaluating CepatEdge, read it like this:

  • The root README.md gives you the technical shape.
  • The docs/ directory gives you the architecture, operations, and institutional story.
  • This why-this-exists.md file gives you the philosophy and 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, that is meant to put power and cost control back in your hands.