Internal simulation layer for pricing scenarios, tariff comparisons and reusable commercial analysis.
Energy Simulator
Internal platform for simulating energy offers, pricing scenarios and commercial workflows with less manual analysis.
Turn complex pricing and offer simulations into a system the commercial team can actually use repeatedly.
FastAPINext.jsPostgreSQLDocker
Casefile Summary
Commercial teams that need to compare offer scenarios without rebuilding the logic each time.
Simulation logic had to stay consistent across repeated runs, not drift between spreadsheets and one-off calculations.
To turn slow manual pricing analysis into one productized workflow with clear backend logic and reusable inputs.
Problem
Commercial analysis was too slow and too manual. Complex scenarios had to be recalculated repeatedly, which created bottlenecks.
Architecture
The platform keeps simulation inputs, pricing logic and reporting surfaces inside one system so the workflow is repeatable and testable.
Web UI -> Simulation API -> Pricing engine
| |
v v
Scenario state PostgreSQL
Key Decisions
- Build a platform instead of collecting scripts and spreadsheets.
- Keep pricing logic centralized so scenario outputs stay consistent.
- Design for repeated internal use, not one analyst working around the system.
System Diagram
flowchart LR
A["Next.js Frontend"] --> B["FastAPI API"]
B --> C["Simulation Engine"]
B --> D["Tariff Sync / Imports"]
B --> E["Celery Jobs"]
C --> F["PostgreSQL"]
D --> F
E --> G["Redis"]
C --> H["PDF / Comparison Outputs"]
Operational Flow
Scenario parameters are captured
Consumption profile, tariff context and commercial variables enter the system through controlled inputs.
Pricing logic runs centrally
The backend applies the same ruleset across scenarios instead of relying on personal calculation sheets.
Outputs are ranked and reviewed
Commercial users compare cases through a reusable product flow rather than rebuilding the analysis each time.
The workflow stays operational
The same platform can be rerun, extended and improved without reauthoring the logic.
Repository Snippet
Based on a real private API router, anonymized down to the useful operational pattern.
@router.post("/batch")
async def create_batch_simulation(
batch_in: SimulationBatchCreate,
service: SimulationService = Depends(get_simulation_service),
):
batch = await service.create_batch(batch_in, current_user)
simulation_batch_task.delay(str(batch.id))
return await service.get_batch_status(batch.id, current_user)
Decision Record
Pricing analysis was valuable, but too slow because each run depended on repeated manual work.
Build an internal platform where simulation inputs, business logic and outputs live in one repeatable flow.
More upfront product work than a script, but far better consistency once several users depend on the process.
Simulation became a shared internal capability instead of an analyst-owned workaround.
Result
Analysis time dropped by roughly 80 percent while the process became easier to reuse and evolve across teams.
Production Signals
- Internal platform used across the company.
- Commercial process moved away from slow manual recalculation.
- Scenario logic became reusable instead of analyst-specific.
- The system was designed to evolve workflows, not just calculate one case.
Verified Repository Shape
Checked against the current private repository. The system is not a single app folder; it is a multi-surface product with explicit runtime boundaries.
- Verified top-level product surfaces include
backend/,frontend/,infra/andops/. - The repo README documents async processing, tariff sync and simulation flows as separate responsibilities.
- The verified stack includes FastAPI, Next.js, PostgreSQL, Redis and OCR/LLM-assisted extraction paths.
Operational Readout
This matters because the repository itself behaves like a product surface: frontend, backend, infrastructure and operations are treated as distinct parts of the same platform.
Captured Screens
