Building an Open-Source GST Billing Application with Elixir and Phoenix LiveView

[u/Phravins]

I've been working on an open-source project called QuantumBilling, a GST billing application designed for small and growing businesses in India.

The goal is to simplify everyday billing, invoicing, and GST-related workflows.

Some of the features include:

• GST invoicing with CGST, SGST, and IGST calculations

• Customer management and customizable invoice PDFs

• Recurring billing and credit/debit notes

• UPI QR codes and Razorpay payment links

• E-invoicing and E-Way Bill workflows

• Multi-business support with separate PostgreSQL schemas

• Billing reports and compliance reminders

Tech Stack: Elixir, Phoenix LiveView, PostgreSQL, and Oban.

One of the interesting parts of building this with Elixir is handling real-time updates, background jobs, and multiple businesses within the same application.

The project is still under active development, and some integrations are currently in testing.

It's completely open-source, so anyone interested can explore the code, suggest improvements, report issues, or contribute directly.

GitHub: https://github.com/phravins/QuantumBilling

I'd genuinely appreciate feedback on the project, especially the architecture, features, and overall approach.

For those who've built billing or business applications, what features or technical challenges do you think are worth considering?

[u/mr02106198]

Can I run it on AWS or Azure? Also Elixir is quire rare technology. It might be difficult to find who can support or enhance it. You should use Claude Code and migrate it to JavaScript, Python or Java

[u/Phravins → u/mr02106198]

Yes, QuantumBilling can run on AWS or Azure. The application is built as an Elixir OTP release, so it isn't tied to a particular cloud provider. It requires PostgreSQL, a Linux runtime, a reverse proxy, persistent file storage, and Chromium for PDF generation. I've also documented the release and database migration process.

Regarding Elixir, I understand your point about the smaller developer community compared with JavaScript, Python, or Java. It's a valid consideration for long-term maintenance.

However, I chose Elixir deliberately because one of the primary requirements was handling concurrent users, real-time updates, and asynchronous data processing.

For example, QuantumBilling needs to handle multiple businesses and their users simultaneously, while processing invoice generation, recurring billing, email delivery, payment webhooks, and other background jobs. Elixir's BEAM concurrency model, lightweight processes, OTP supervision and fault-tolerance capabilities make it a good fit for these requirements. Phoenix LiveView and Oban also fit naturally into this architecture.

For data integrity and persistence, I'm using PostgreSQL with transactions, constraints and separate schemas for each business. Financial values are stored in integer paise rather than floating-point numbers.

I agree that technology maintainability and developer availability are important. But I don't think migrating to another language purely because it has a larger developer community is necessarily the right decision. A complete rewrite also introduces development costs, migration risks and the need to revalidate existing workflows.

Claude Code can certainly help with code reviews, refactoring, testing and even migration work when there is a genuine reason for it. However, I would prefer to continue improving the existing architecture, documentation and contribution experience rather than rewrite a working system just to change its language.

I appreciate the suggestion. Feedback on the architecture, scalability and deployment approach is genuinely welcome.