Skip to main content

Capability proof · our own operating system

We built the system our own company runs on.

OSCERP is the internal ERP behind Oscillate Infotech — delivery, finance, payroll, attendance and company records in one system. It is not sold and not self-serve. It is the clearest evidence of how we design a business operating system that people actually use every day.

Internal productNext.js · TypeScript · MongoDB
What it is
An internal ERP, not a product for saleOne login, one database, one system for the whole company.
Who uses it
Super admins, managers, employeesEach role sees a different scope of the same records.
How it is built
Next.js · TypeScript · MongoDBOne hand-written design system, no UI kit, no second design language.

Why it exists

A company should not have to remember where its records live.

Like most growing firms, we ran on a patchwork: a spreadsheet for one thing, a tool for another, an email thread standing in for approval. Each part worked. Together they disagreed. OSCERP exists to end that disagreement — one login, one database, one system — and every feature has to earn its place by answering a single question: does this reduce dependency on another tool?

What it took over

  1. 01Shared spreadsheets used as the source of truth
  2. 02A separate HRMS for employee records
  3. 03A separate attendance tool
  4. 04A separate leave tool
  5. 05A separate payroll tool
  6. 06A separate project management tool
  7. 07A separate employee self-service portal
  8. 08Email threads standing in for an approval trail
OSCERP dashboard: invoiced, collected, outstanding and payroll status figures above a cash position chart, an attention queue of overdue and pending items, a delivery load chart and an activity log
Interface preview · sample dataThe super admin dashboard answers what is happening across the company: money in and out, work at risk, and who changed what.

The joins

Four operating areas that stopped being separate.

Most of the value is not in any single module. It is in the fact that a project, an invoice, an attendance mark and an approval all reference the same records.

  1. 01

    Operations

    Where does the work live?

    Projects, tasks, teams and documents share one record, so a status change is visible to everyone who needs it instead of being re-typed into a tracker.

    • Projects
    • Tasks
    • Task performance
    • Team
    • Documents
    • Announcements
  2. 02

    Finance

    What has been billed, and what has actually arrived?

    Clients, invoices, payments and credit notes settle against the same receivables ledger, and cash position is read from those records rather than assembled by hand each month.

    • Clients
    • Invoices
    • Payments
    • Credit notes
    • Cash flow
    • Reports
  3. 03

    People

    Who is in, who is off, and what does payroll owe?

    Attendance, leave and payroll run on one roster. A leave approval and an attendance exception both land in the same place the payroll cycle reads from.

    • Attendance
    • Leave
    • Payroll
    • Employees
    • Reimbursements
    • HR letters
  4. 04

    Administration

    Who changed what, and who was allowed to?

    Roles, permissions, settings and the activity log sit with the same system that holds the records, so access and history are not a separate exercise.

    • Roles & permissions
    • Settings
    • Activity log
    • Notifications

Representative workflows

What the system is actually doing all day.

Three sequences that show the shape of the build: each one crosses a boundary that usually needs a human to carry data across it.

OSCERP projects list showing project, client, owner, next milestone, progress and status columns, with a record inspector open on one project listing its milestones
Interface preview · sample dataDelivery workspace. Selecting a project opens an inspector with its owner, team, milestones and open work — the same record the dashboard counted.
  1. 01

    A receivable, from raised to reconciled

    1. An invoice is raised against a client and a project.
    2. Payments are recorded and allocated to specific invoices, not to a running total.
    3. Credit notes and adjustments post against the same invoice.
    4. The balance and the cash position follow from those entries automatically.

    Because every line is backed by its own record, an outstanding figure can be traced back to the entries that produced it.

  2. 02

    A month of attendance into a payroll run

    1. Attendance is captured in the app and marked against the roster.
    2. Leave requests are approved by a manager, within a manager-level ceiling.
    3. Exceptions — a missing punch, an unapproved absence — are surfaced before anything is locked.
    4. The payroll cycle reads the closed month and generates salary slips.

    The sequence is deliberate: payroll cannot quietly run on top of unresolved attendance.

  3. 03

    Work from brief to record

    1. A project carries its client, owner, milestones and documents.
    2. Tasks are assigned with owners and due dates rather than left implicit.
    3. Status and milestone changes are written to the activity log with old and new values.
    4. Dashboards read from the same records, so nothing is re-keyed to report on it.

    The reporting layer and the working layer are the same data, which is why the numbers agree.

OSCERP invoice register with amount, balance and status columns, a payment allocation panel breaking one invoice into payments and a credit note, and an invoiced versus collected chart
Interface preview · sample dataReceivables. An invoice balance is the sum of what has been allocated against it, so the outstanding figure is auditable rather than asserted.

Control & record safety

Everyone sees the same truth, scoped to their role.

A shared system only works if people can be trusted with it. Scope is defined by role, approvals are explicit, and history is not something the system quietly overwrites.

Super admin

Full system scope: users and permissions, finance, payroll, projects, employees and settings.

Manager

Team scope: assign and review work, approve leave, watch attendance and project status — without payroll configuration or company financial administration.

Employee

Self-service scope: own profile, attendance, leave, salary slips, assigned work and the documents shared with them.

  • Permissions are checked on routes and APIs

    Access is enforced where the data is served, not only by hiding menu items in the interface.

  • Important actions are logged

    Creates, updates, approvals, rejections, assignments and status changes record the user, the entity, the timestamp and the values before and after.

  • Finance entries are backed by vouchers

    Ledger movements carry their own record, so a statutory figure can be followed line by line instead of being taken on trust.

  • Records are preserved, not deleted

    Migrations are non-destructive by policy. Payroll, attendance, leave, invoice and activity history stay intact.

OSCERP attendance screen with a month calendar of presence marks, a daily register of in and out times, a leave approval queue and a payroll cycle checklist
Interface preview · sample dataAttendance, leave and payroll in one place. The payroll cycle stays in draft until the month’s attendance exceptions are resolved.

Engineering approach

Built to stay maintainable after the launch week.

An internal system is judged years later, not on demo day. These are the choices that keep it workable as the data grows and the team changes.

Framework
Next.js App Router with TypeScript across the server and client
Data
MongoDB with Mongoose models, server-side search, filtering, pagination and aggregation
Access
Session authentication with role-based route and API permissions
Interface
A single hand-written CSS design system — consistency chosen over novelty
Operations
Documented backup, restore testing, deployment and incident runbooks
Discipline
Phase gates and non-destructive migrations; new modules wait behind fixing existing ones

What this demonstrates

If we will run our own company on it, we can build yours.

OSCERP is not a template we resell. It is the same work we do for clients, applied to ourselves and lived with daily: understanding how a business actually operates, deciding what belongs in one system, and building something people prefer to the spreadsheet they had before.

Your operation is not ours, so a system for you would not look like this one. The method would be the same — map the real workflow, join the records that keep drifting apart, and put the controls where the data is.

See systems we built for clients

Next step

Discuss a system for the way you actually operate.

Tell us where your records disagree with each other. We will tell you honestly whether a tailored system is the right answer.