From idea to a finished project
Turnkey custom development of information systems. On my own open-source platforms A-POST-OL and db-platform, proven in production since 2017.
How it works
From architecture to production and maintenance. One person accountable for the result.
Understand the task
I dig into your business processes and goal. Not "code to spec" - I understand what must work and why.
Design the architecture
For the business goal, timeline and budget. A minimally sufficient solution instead of fashionable over-engineering.
Ship to production
On a ready foundation: auth, REST, workflow, files already exist. The budget goes to your logic, not infrastructure.
Maintain it
Operation, evolution, hand-off. The system lives for years - not "delivered and forgotten".
Custom Development
Projects on the A-POST-OL platform built for individual customer requirements. Each project is an active system you can open and verify.
ChargeMeCar
Production CSMS for managing EV charging infrastructure in Europe. OCPP 1.6/2.0.1, OCPI 2.2.1/2.3.0, AFIR, Stripe. A brand on the Apostol CSMS platform.
CopyFrog
AI-based platform for generating ad copy, images, and video creatives for products and services.
OCPP CSS
A comprehensive solution for charging station owners and drivers. OCPP 1.6/2.0.1, OCPI 2.2.1/2.3.0, AFIR, Yookassa. A brand on the Apostol CSMS platform.
Ship Safety ERP
Safety management system for shipping companies. SOLAS, ISM Code compliance. Registered in the Russian Software Registry.
Apostol ARB
SaaS service for crypto futures arbitrage. Binance, Bybit, OKX, MEXC, Bitget. Real-time data, automated analysis.
DEBT-Master
Automation of consumer utility debt collection and management.
Campus CORS
Real-time GNSS correction system. NTRIP protocol. Base station network for precise positioning.
Talking To AI
Telegram chatbot for AI conversations (ChatGPT). Implemented entirely in PL/pgSQL - from business logic to OpenAI API integration.
And it runs for years
Fast and reliable
Development moves fast and the result holds up in production for years. Here's why:
A ready foundation
db-platform covers many months of infrastructure out of the box: authentication, REST API, workflow, files, queues, audit log, localization. The project budget goes to your business logic, not to reinventing the wheel.
One person - a team's output
Own platforms as the foundation plus AI tools in development, review and documentation deliver output comparable to a team - with one point of accountability and direct contact with the architect.
Production reliability
24/7 operation, zero-downtime deployment, dev/stage/prod separation, migration control. Engineering discipline from the banking domain, where the cost of a mistake is money and regulation.
Platform
A-POST-OL - open-source platform for backend development. C++20 + PostgreSQL. Two frameworks, one binary.
Every project starts not with business logic but with a foundation: login and access control, file storage, business processes, notifications, logging, reports, integrations. On a conventional stack that's the first months of work and a sizeable slice of the budget - spent not on what the project is for, but on engineering plumbing you can't do without. And that's exactly where delays, bugs and security holes tend to accumulate.
The platform is that foundation - already built, refined over years and proven not on one but on a dozen systems in real production. You start not from zero but from a solid base: time and budget go to your project's business logic - the part that sets it apart and earns money - instead of re-laying what has already been built and battle-tested many times over.
Zero layers between request and database
Most frameworks insert several intermediate layers between an HTTP request and PostgreSQL - an ORM, a separate connection pool, their own IO cycle. A-POST-OL removes the unnecessary parts: HTTP and PostgreSQL run in the same epoll loop. The result is not just speed - it is architectural simplicity: fewer moving parts, fewer places for bugs, fewer extra services.
Data consistency
Business logic lives inside PostgreSQL itself: transactions, stock checks, price calculations, double-charge protection - atomic at the database level, no intermediate layers. Critical for e-commerce and financial operations. A similar approach to Supabase, but their logic is limited to RLS and edge functions - here all business logic is in PL/pgSQL.
A single event loop, async PostgreSQL with no threads or blocking calls - a consequence of the same architecture. Open benchmark:
What you get out of the box
Login & access control
Sign-up, sign-in (including OAuth2 and social), roles and fine-grained "who can see and do what".
Documents & catalogues
One model for clients, accounts, orders, contracts - with change history and lifecycle.
Business processes
Statuses and transitions (request → in progress → closed) configured as data. The process changes without rebuilding the system.
Files & storage
Attachments, scans, photos. S3-compatible cloud storage out of the box.
Notifications & real time
Instant UI updates, email/SMS/push, email and phone verification.
Audit log
Who did what and when - a full trail for disputes and regulatory requirements.
Reports & exports
Building reports and documents from the system's data.
Integrations
A ready REST API with hundreds of methods, inbound webhooks and calls to external services - payment systems, AI, government services - straight from the system.
Dozens of modules · hundreds of ready REST API methods · multi-language · Russian address registry (KLADR) · runtime configuration without a developer
Ready-made subsystems
Beyond the basic blocks - whole business mechanisms, already assembled and proven across several projects. No need to design them from scratch.
Payments & acquiring
Accepting payments via Stripe, YooKassa and CloudPayments for different markets - through one interface. Card binding and auto-charge, amount reservation (pre-auth hold), refunds, card validation, invoice settlement.
Account ledger (double-entry)
Personal accounts: wallets, liabilities, debts. Debit and credit turnover, opening and closing balances, a turnover report with day/week/month aggregation. Accounting rigour at the database level.
Subscriptions & billing
Products, plans and periods; scheduled auto-renewal, trial period, plan change with pro-rata recalculation, cancellation. The full subscription lifecycle, tied to limits (e.g. number of devices).
The same blocks power systems for EV charging, AI generation, geodesy and utility-debt collection.
A-POST-OL (libapostol)
C++20 framework. HTTP/WebSocket server, async PostgreSQL, single epoll event loop. Automatic OpenAPI spec + Swagger UI generation.
github.com ↗PostgreSQL Framework for Backend Development
Dozens of PL/pgSQL modules: REST API, OAuth 2.0, workflow engine, file storage, pub/sub, report system. Turns PostgreSQL into a full-featured application server.
github.com ↗The platform - a three-layer toolkit
Same stack across many production projects. Only the top layer - business logic - changes.
Configuration - your project
Unique business logic. Everything that makes CSMS different from an ERP lives in this layer.
auth · OAuth 2.0 · workflow · entity · files (S3) · pub/sub · audit log · notifications · localization · reports · registry · KLADR · …
Dozens of modules · hundreds of REST methods · nobody writes a line in this layer
HTTP / WebSocket · TLS · epoll · libapostol
Like nginx or PostgreSQL itself - not part of your project.
Dozens of platform modules are reused across many projects without writing a single line of their own. The Stripe payment module, written for CopyFrog, is reused as-is in other projects - for example, in Apostol CSMS. The same principle assembles an e-commerce site, an ERP, or an IoT platform - unique logic lives only in the top layer.
Workflow engine - as data
States, transitions, and events of your business processes are stored in DB tables, not in code. Change the workflow without redeploying the service.
- in practice, this is the decision that keeps proving itself the most useful in the platform's architecture.
Time is money
The platform is not just technology - it's many months of team work that, in a typical project, gets spent on infrastructure: auth, workflow, REST, files, queues, audit log, localization. Here it already runs in production across many systems. Your project's budget stays on business logic, not on reinventing the wheel.
- in my own estimate, rebuilding a comparably mature system from scratch on a standard stack, with no new features, would take years of development and millions in budget.
One Key Difference
The three-layer constructor is the WHAT. Below is the WHY - why this architecture instead of the standard stack. For those who want to understand it in five minutes.
Take a concrete task: "Check balance and charge money" It appears in every transactional project - e-commerce, billing, ERP, utility collection.
In Python / Node.js / Go:
HTTP request
↓
App server (Python / Node.js / Go)
↓ ← round trip 1
SELECT balance FROM db ──────→ PostgreSQL
↓
[in-memory logic]
if balance >= price:
↓ ← round trip 2
UPDATE balance - price ──────→ PostgreSQL
INSERT INTO orders … ──────→ PostgreSQL
↓
HTTP responseThe problem: a temporal gap
Between SELECT and UPDATE there is a temporal gap. A concurrent request can read the same balance before the first one has updated it. Result: double charge, oversell, booking race. The fix - explicit extra mechanics: SELECT FOR UPDATE, optimistic locking, Redis lock. These are well-known tools - but they are extra code, extra dependencies, and extra places for bugs.
In A-POST-OL:
HTTP request
↓
C++ worker (epoll)
↓
libpq async: SELECT debit(user_id, amount) ──→ PostgreSQL
┌──────────────────────────┐
│ PL/pgSQL function: │
│ SELECT balance │ ← one transaction,
│ IF balance < amount │ atomic,
│ RAISE EXCEPTION │ no temporal gap
│ UPDATE balance │
│ INSERT INTO orders │
└──────────────────────────┘
↓
HTTP responseNo gap. No three round trips. No extra locks. PostgreSQL serializes concurrent calls on its own - that is an ACID property, not extra code.
When inter-process data transfer is needed
e.g. an event stream from an external source (IoT, exchange, telemetry)
In Python:
Process A → parse → dict → Pydantic → JSON → Redis XADD ← network call Redis XREAD → JSON → Pydantic → Process B
A typical Python event-processing service performs 5–7 serializations per event. At 1,000 events/sec that is thousands of operations just to pass a number from one own process to another. CPU goes to transport, not business logic.
In A-POST-OL:
External source (WebSocket)
↓
Process A → parse
→ cache[key] = value ← in memory
Process B reads same cache
↓
libpq NOTIFY → PostgreSQL → WS pushNo Redis. No JSON between own processes. 0 serializations.
Why this is possible: the PostgreSQL socket at arm's length
Python / Node.js / Go
In Python/Node.js/Go - PostgreSQL is an external service. Every call: borrow connection from pool → send over TCP → wait → receive → parse. Even with an async driver - that is a separate IO loop with overhead.
A-POST-OL
In A-POST-OL - the PostgreSQL socket is registered in the same epoll loop as the HTTP sockets. When the database responds - epoll fires the same way as when a client sends the next byte. No separate thread waiting. No context switch. No queue between "received HTTP request" and "answered from database".
| Python / Node.js / Go | A-POST-OL | |
|---|---|---|
| PostgreSQL access | TCP + parse + thread pool | epoll event in the same loop |
| Inter-process transfer | Redis / Kafka / gRPC | libpq NOTIFY / memory |
| Race on check + update | explicit locks required | eliminated architecturally |
| Redis as cache | needed - PG is "far" | not needed - PG is already "close" |
| Message broker | needed for async workflow | PostgreSQL LISTEN/NOTIFY |
That is why 507K RPS even though every request touches the database. That is why no message broker is needed for internal communication. That is why business logic can live inside a transaction without overhead - because a database call costs the same as processing the next HTTP packet.
A-POST-OL was built as an answer to one specific question: how to remove all layers between an HTTP request and a PostgreSQL transaction. OCPP (the EV charging protocol) is a clear example where this matters acutely: thousands of stations, persistent WebSocket connections, every message must land in the database atomically and immediately. The same architecture works in ERP, fintech, and IoT - because the requirement is the same: data is consistent, not "eventually consistent". The price of this architectural choice is business logic in PL/pgSQL instead of the familiar Python or Go. Developers who write application-level code in PL/pgSQL are relatively rare. This is a real constraint worth knowing upfront.
The platform is a core you connect microservices to, in whatever language fits. DEBT-Master runs five Python services around the core (Excel/PDF/RTF parsing, OCR, document generation); CopyFrog orchestrates AI providers. The right tool for the job - not "everything in one stack at any cost".
A factory, not a garage
You get not a lone machine in a garage, but a complete factory with many independent production lines: they don't all go down together, they self-heal on the fly, and they update without stopping. Maturity proven by years in production.
An A-POST-OL application is a single binary running independent modules under a master process: HTTP handler, WebSocket server, task scheduler, report generator, OCPP processor - each as a separate "service". One crashes - the others keep running, the system brings up a replacement on its own. No network calls between own components: everything runs in one process and one epoll loop. In essence - microservice isolation without microservice infrastructure.
Microservices are a fleet of separate trucks: one breaks down, the others keep delivering - but you run a whole logistics company to coordinate them. A-POST-OL is one well-built factory with independent lines: a line jams, the others keep running, and the foreman restarts it at once. And to survive the whole factory burning down, you build a second factory - exactly like everyone else.
Reliability isn't that nothing ever breaks - it's that a breakage doesn't take everything down.
Reliability on par with nginx and PostgreSQL
Inside, the system is built the same way as the most trusted software in the world - the web servers and databases banks rely on: a master process supervises many workers. One falls - the others keep serving, and the system brings up a replacement itself. Background services (mailouts, schedules, reports) run separately: the report generator dies - request handling is unaffected. That's the very isolation microservices boast about - already inside a single application.
Updates roll out smoothly, with no downtime - users don't notice. And to survive a whole-server failure or huge load, you add the ordinary, boring set: a second server behind a load balancer and a copy of the database. It's standard and plugs in when you actually need it - the architecture doesn't get in the way.
What this gives you
A failure doesn't bring it all down
A single service can crash and restart itself - the system keeps running.
Updates with no downtime
New versions come up smoothly; users see no interruption.
Grows with you
For server failover and heavy load you add a standard set - not before you need it.
Microservices give this resilience out of the box, but at the cost of constant operational complexity. Here reliability is there from the start, and scale is added as needed - for most business systems that's the more sober choice.
The platform architecture is universal
The platform fits any project that needs a reliable backend with built-in infrastructure. Apostol CSMS is just one example. Your project can be next.
E-commerce
Multi-tenant, multi-payment, country-based tax calculation, queues for marketplace integrations (Amazon, Shopify), audit trail, oversell protection.
FinTech
Real-time data via WebSocket, OAuth 2.0, billing and reconciliation, audit trail, exchange and payment integrations.
ERP / document workflow
Workflow engine (states, transitions, events), document management, reports, S3-compatible file storage, localization.
IoT and charging infrastructure
High load via single event loop, persistent WebSocket connections, OCPP/OCPI/MQTT, real-time telemetry processing.
AI services
Async tasks, queues for LLM APIs, file storage for inputs and results, usage-based billing, multi-tenant.
General-purpose SaaS
Authentication out of the box (OAuth 2.0, JWT, signup), tenant isolation, white-label, localization, audit trail - everything a starting SaaS needs.
Ideal fit
- ✓Transactional systems: fintech, billing, e-commerce, ERP, payments, utility automation
- ✓Real-time and long-lived connections: IoT, charging (OCPP), telemetry, streaming, WebSocket
- ✓Multi-tenant SaaS / white-label, 24/7 operation, cheap to run
- ✓Integration hubs - orchestration straight from the database
Better to look elsewhere
- →Frontend/UX-first products with a thin backend - the platform is overkill
- →Products whose core value is ML/AI pipelines (the platform only fits around them)
- →When you need to hire a large team fast and value mainstream-stack liquidity
- →Global horizontal scale from day one
Apostol CSMS (EV charging infrastructure) is one example of a mature SaaS product on the platform. Same architecture, different domain.
Learn more about the platform architecture →Your project - your code
Contractor independence is built into the architecture.
Open foundation
The A-POST-OL and db-platform frameworks are open-source (MIT), in production since 2017. No closed "black box".
You own the sources
Project code stays with the client. Business logic is written in PL/pgSQL - a SQL dialect of PostgreSQL, readable by any developer who works with databases.
Hand-off ready
The project can be maintained and evolved by any PostgreSQL developer - no lock-in to one person.
Terms & Pricing
Two ways to work
Turnkey
I take the whole project - from architecture to production and maintenance. One point of accountability.
$100/hour
$800/day · $4,000/week · $16,000/month
Inside your team
I join your team on a project basis or reinforce the backend. I work within your processes.
$60/hour
$480/day · $2,400/week · $9,600/month
Minimum engagement - one week per month; you decide the rest.
Project cost
To gauge the total cost of a project:
| A compact MVP or an integration on the ready foundation | 1-1.5 months | $16,000-24,000 |
| A production system with several user roles and payments | 3-5 months | $48,000-80,000 |
| A multi-tenant SaaS at the Apostol CSMS scale | 6+ months | $96,000+ |
Exact figures - after a short call to scope the task. Engagement can stay partial: a smaller budget means fewer hours a week, not no contractor at all.
About the developer
Alen Prepodobny - a sole proprietor since 2021. 25+ years in IT, 10+ of them as a technical director; I grew up in banking IT, where the cost of a mistake is measured in money and regulation. I take a project, dig into the client's business processes, and carry it from idea to production - then maintain it. A-POST-OL and db-platform are my own tools, grown out of real projects: EV charging, maritime safety, fintech, geodesy.
Custom development
- •Frog IT SARL (France) - for clients in the EU
- •IE Prepodobny Alen Alekseevich - for clients in Russia
Get in touch
Describe your task - I'll respond within a day
What happens next
- 1I respond within a day - personally, not a bot or an account manager.
- 2We hop on a 30-minute call - free, no obligations, just to scope the task.
- 3I send a written estimate of timeline and budget - then it's your call.