Skip to content

Custom business software / ERP

Integrated Business Management System — Website, ERP and Financial Operations

A custom business management system that connects the customer-facing website with customer and product management, account ledgers, debt and collection tracking, VAT calculations, cash, cheque and promissory-note operations, and operational reporting on one data model.

Developed by
TankDev
Project type
Client work · custom business software
System
Web application + ERP management layer
Field
Business management · financial operations
Core modules
Customers · products · ledgers · collections · reporting
Frontend
Next.js · Tailwind CSS
Backend
FastAPI
Database
PostgreSQL
Platform
Web
Status
Working system

PUBLIC WEB × BUSINESS OPERATIONS

From web project to business system

This project was not limited to rebuilding a corporate website. A custom ERP layer for the company’s day-to-day operations was developed inside the same system.

Customer records, product definitions, financial transactions, collections, payment instruments, and reporting were brought together around one backend and central data model. The public web experience and internal operations were treated as one engineering system.

Verifiable system scope

These indicators describe the verifiable scope of the software delivered, not commercial outcomes or usage volume.

01Shared operational data model
08Business modules
03Payment instrument types
95+PageSpeed measured categories

The Problem Beyond the Website

A company’s digital system is more than the pages its customers see. Customers, products, amounts, VAT, account-ledger transactions, debts, collections, payment instruments, and reports are connected operational data. In this project, the public website and internal operations were designed as one system around a shared backend and data model, not as two disconnected products.

Engineering constraints

The system had to preserve relational integrity across financial records, associate customers with the correct transactions, and represent cash, cheques, and promissory notes within one financial model. New product definitions could not disrupt existing workflows; reports had to derive consistently from operational data; and the public website and internal management interface had to serve different users within one architecture.

DOMAIN MODEL

One System, Connected Business Data

Keeping customers, products, and financial transactions in a relational model—rather than as isolated records—allows person-, date-, and transaction-based reports to be produced from the same operational data.

ERP MODULES

A Custom ERP Layer

01

Customer Management

Create and maintain customer records, with linked operational and financial activity kept in one place.

02

Product Definition

Business users can define a new product or service and associate it with the relevant customer workflow.

03

Customer Account Ledger

Track financial transactions and the current financial position for each customer.

04

Debt and Collections

Record debts, process collections, and reflect each financial transaction in the customer account.

05

VAT Calculation

Manage transaction amounts and VAT calculations within the system workflow.

06

Payment Instruments

Record cash, cheque, and promissory-note payment or collection types.

07

Cheque / Note Status

Manage operational status changes for cheques and promissory notes and connect them to the relevant financial transaction.

08

Operational Reporting

Produce person-, date-, and transaction-based reports from operational records.

SYSTEM ARCHITECTURE

The Customer-Facing Web and Internal Operations Share One Architecture

The Next.js web layer, business rules in FastAPI, and relational operational data in PostgreSQL operate within one system boundary.

FINANCIAL OPERATION FLOW

How a Transaction Moves Through the System

This flow explains the system’s business domains without publishing client-specific accounting rules or formulas.

  1. 01Customer
  2. 02Product / Service
  3. 03Amount
  4. 04VAT
  5. 05Ledger transaction
  6. 06Debt
  7. 07Collection
  8. 08Cash / Cheque / Promissory note
  9. 09Financial position
  10. 10Reporting

REPORTING

From Operational Data to Reporting

Data created in the system is not stored only as a record. The same central data supports customer or person, date, and transaction views. Operational records and reporting are handled as different views of one data model rather than disconnected processes.

  • 01Customer / person
  • 02Date
  • 03Transaction

Delivered Scope

Traditional website scope

  • Public pages
  • Content
  • Contact
  • Customer-facing experience

Delivered system

  • Public website
  • Customer management
  • Product definitions
  • Account ledgers
  • Debt and collections
  • Cash / cheque / promissory note
  • Financial operations
  • Reporting
  • Central database

Why This Is More Than a Website

A website is the digital surface customers see. In this project, the same software system also manages customer records, product definitions, account ledgers, collections, payment instruments, and reporting. Because the public web, operations, and financial data work around the same backend and data layer, the delivery is custom business software connected to day-to-day operations.

Engineering Approach

Next.js provides a fast, crawlable public web layer. FastAPI keeps business rules and data access for public and internal interfaces behind one API boundary. PostgreSQL preserves relationships across customers, products, and financial operations. Tailwind CSS supports a consistent responsive interface across workflows.

Performance in the Public Web Layer

Measured categories in Google PageSpeed Insights tests score at 95+. This describes PageSpeed measurement categories; it is not a Core Web Vitals claim, a ranking claim, or a commercial-performance metric. Detailed category scores are not published without the measurement capture.

Technical Search Infrastructure

The public web layer provides crawlable page content, semantic HTML, page-level metadata, self-referencing canonical URLs, sitemap entries, robots directives, structured data, and responsive design. Turkish and English versions are connected through reciprocal hreflang links.

Data and Publication Boundaries

This case study does not publish real customer records, financial amounts, account details, cheque or promissory-note numbers, or client-specific calculation rules. It makes no unverified claim about security certification, the authorization model, or audit logging.

Related capabilities

Are separate systems still running behind your website?

Customer, product, financial transaction, and operational data can be brought together in one software system built around your business.

Tell us about your projectCustom Software Development
WhatsAppDirect contact