TURNING IDEASINTO SYSTEMS,RESPONSIBILITYINTO LEGACY
- ERP
- POS
- ACCOUNTING
- OPERATIONS
- AUTOMATION
I am Adesh Lande. I design and build practical software systems for businesses — from billing screens and inventory flows to multi-tenant architecture, accounting engines and operational platforms.
- 01Sceneway HMSSYS_001 · HOTEL ERPLIVE2026
- 02LogixmapSYS_003 · FLEET SYSTEMBUILDING2026
- 03GasMitraSYS_004 · GAS AGENCY ERPLIVE2026
- 04VS AccountsSYS_002 · ACCOUNTING ENGINESYSTEM2026
- 05Contractor ERPSYS_005 · PROJECT OPSBUILDING2026
- 06Dairy SystemSYS_006 · COLLECTION ERPLIVE—
- 07Business MessengerSYS_007 · COMMUNICATIONR&D—
- 08Workflow EngineSYS_008 · AUTOMATIONLAB—
ONE PROPERTY.FIVE OPERATIONS.ONE LEDGER.
SCENEWAY HMSHotel & Restaurant Operations System
Sceneway treats a property as a single ledger with several front-ends. Every operational screen — a check-in, a KOT, a stock issue, a purchase entry — is an event. Events post to inventory and to accounts as a consequence of being recorded, not as a separate month-end exercise.
The room register and the restaurant POS are deliberately the same system. A resident guest can sign a restaurant bill to their room folio, and it lands on the folio, the outstanding and the day book at once.
Multi-property is handled at the data layer through tenant and property scoping, so a group can operate several hotels with isolated data and consolidated reporting.
- Rooms and restaurant on the same system, not two integrations
- Recipes convert covers sold into stock consumed
- Restaurant bills post straight to a room folio
- Business date on every posting makes night audit deterministic
- Reservations, check-in/out, folios, tariff and tax plans
- Restaurant, bar and room-service billing; table and cover management
- Kitchen order tickets routed per station; fires recipe consumption
- Stores, issues, transfers, physical verification and variance
- Roles, shift assignment, per-user audit trail on every posting
- Supplier bills, receipt against order, rate history, payable ageing
- Bill of materials per dish; converts covers sold into stock consumed
- DAY BOOK
- LEDGERS
- OUTSTANDING
- STOCK VALUATION
- REPORTS
Rooms, POS, KOT, inventory, staff, purchase and recipe modules all post into a shared accounting core, which produces the day book, ledgers, outstanding balances, stock valuation and reports.
A hotel with a restaurant attached does not run one business — it runs five. The front desk sells rooms. The restaurant sells covers. The kitchen consumes stock. Purchase brings stock in. Accounts has to reconcile all of it by the end of the day. Read the full case study.
ONE ACCOUNTING ENGINE.MULTIPLE BUSINESS SYSTEMS.
VS ACCOUNTSShared Accounting Engine
VS Accounts treats accounting as infrastructure. It owns the chart of accounts, journals, vouchers, allocation and reporting, and exposes posting as a service that any product can call.
Business systems do not write journal entries by hand. They describe a business event — a sale, a receipt, a stock consumption, a trip cost — and a mapping layer turns it into a balanced set of entries. The product knows its domain; the engine knows accounting.
Every posting is idempotent and traceable back to the source document in the originating system, so a figure in a report can always be walked back to the operation that caused it.
- Products emit business events, not journal entries
- Posting rules are versioned, so closed periods reproduce
- Every entry traces back to its source document
- Corrections are reversals — history never changes
- Room and restaurant sales, folios, purchase, stock consumption
- Cylinder sales, deposits as liability, receipts and allocation
- Project cost, labour, supplier bills, running-account billing
- Collection payable to farmers, deductions, cycle payouts
- A new product integrates by mapping its events, not by rebuilding a ledger
- LEDGERS
- JOURNALS
- OUTSTANDING
- TRIAL BALANCE
- REPORTS
Sceneway, GasMitra, Contractor ERP, Dairy and future products all post into a single shared accounting engine, which produces ledgers, journals, outstanding balances, trial balance and reports.
Every business system eventually needs accounting. A hotel needs it, a gas agency needs it, a contractor needs it, a dairy needs it. The usual outcome is that each product grows its own partial ledger — a sales table here, an outstanding column there — and each one gets the hard parts slightly wrong in a different way. Read the full case study.
A TRIP IS NOT DONEUNTIL IT IS PROVENAND SETTLED.
LOGIXMAPFleet, Tour & Driver Operations
Logixmap models a tour as the unit of work. A tour is planned, assigned to a driver and a vehicle, executed with stage and location updates, expensed against a budget, evidenced with documents, and only then closed.
- Driver scheduling with duty-hour checks
- Location reported only while a tour is active
- Trip expenses captured at the fuel pump, not at month end
- Role hierarchy enforced in the query, not the UI
- Route, stops, vehicle, expected cost and time window
- Assignment with availability and duty-hour checks
- Fuel, toll, loading and advance recorded against the tour
- Photo of slip, delivery note or signature, stamped with time and location
- Tour closed, driver advance settled, cost posted to accounts
A tour moves through five stages: tour planning, driver assignment, expense capture, proof of delivery, and completion with settlement.
- Sees only own assigned tours, own expenses, own documents
- Location is reported only while a tour is active
- Cannot edit a closed tour or a settled expense
A manager node with three driver nodes beneath it; each driver can only see their own tours and expenses.
EVERY CYLINDER OUTIS A CYLINDER OWED.
GASMITRAGas Agency Operations System
GasMitra tracks cylinders as a two-way movement. An order produces a delivery, the delivery expects an empty return, and the return, the bill and the payment together settle the customer position.
- Cylinders modelled as positions, not a stock number
- Empty returns reconciled against every delivery
- Deposits held as a liability, not booked as income
- Receipts allocated against bills, so ageing is real
- Domestic or commercial connection with deposit, quota and rate class
- Booked by phone, counter or route plan, then queued to a delivery round
- Full cylinder issued against the order; stock and route load updated
- Empty received back and reconciled; a shortfall becomes a tracked liability
- Rate class applied, taxes computed, document numbered and printed
- Cash, transfer or credit; partial receipts allocated against bills
- Sale, tax, stock and receipt posted as one balanced transaction
- Cylinder position, route performance, ageing outstanding, tax summary
Business flow running from customer to order, cylinder delivery, empty return, bill, payment, accounting and finally reporting.
Six rules that decide how a system gets built.
Not opinions about frameworks. These are the decisions that determine whether business software still works in year three.
- 01
Software starts with the business flow.
Understand what actually happens at the counter, the warehouse, the office or the hotel before designing tables. The schema is a consequence of the operation, not the other way round.
- 02
Accounting should happen automatically.
A business event should generate its accounting consequence at the moment it is recorded. If someone has to re-enter the day into accounts later, the system is only half built.
- 03
Data belongs to the tenant.
Every system is designed with tenant isolation from the first migration. Scope is resolved server-side from credentials, never from something the client sends.
- 04
Offline is not an afterthought.
Operational software has to survive an unstable network. Queued operations with idempotency keys are cheaper to design in than to retrofit after the first lost day of billing.
- 05
The UI should reduce work.
A billing operator using software for eight hours a day does not need decorative animation. They need fewer keystrokes, predictable focus order and a screen that does not move under them.
- 06
Architecture should survive growth.
A system designed for one business should have a visible path to ten and a hundred. Usually that means shared infrastructure — accounting, identity, workflow — instead of a fork per customer.
What I actually work with.
Listed as a matrix because that is what it is — a set of tools applied to a set of problems, not a scoreboard.
FRONTEND
06- Flutter
- Flutter Web
- TypeScript
- React / Next.js
- Responsive UI
- Operator-speed forms
BACKEND
06- Node.js
- REST APIs
- Authentication
- Multi-tenancy
- Background processing
- Idempotent posting
DATA
06- MySQL
- PostgreSQL
- Neo4j
- Redis
- IndexedDB
- Schema & migration design
ARCHITECTURE
06- Multi-tenant SaaS
- RBAC
- Offline-first
- Accounting integration
- Inventory systems
- Real-time workflows
INFRASTRUCTURE
06- Windows Server
- IIS
- Linux
- SSL
- Reverse proxy
- Deployment & rollout
EXPLORING
05- AI agents
- Voice interfaces
- Graph systems
- Vector search
- Business automation
- LAB_01PROTOTYPE
AI Operators
Voice-driven interfaces that understand the currently focused field and assist an operator without automatically committing a transaction. The interesting constraint is that an assistant in business software must never post on its own — it should prepare, explain and wait.
- LAB_02EXPLORING
Graph Systems
Graph-based relationships for permissions, recipes and operational dependencies. Questions like which dishes are affected if this ingredient runs out, or who can approve this document, are natural traversals and awkward joins.
- LAB_03ACTIVE
Offline Systems
Robust local-first architecture for business applications: durable queues, conflict rules that a non-technical operator can understand, and a sync state that is always visible rather than hidden behind a spinner.
- LAB_04EXPLORING
Search
Fast search over large operational datasets — customers, items, documents and history — where the answer has to appear in the same keystroke rhythm as typing, on hardware that is a decade old.
- LAB_05BUILDING
Workflow Engine
Node-based modelling of business processes so approval chains become configuration rather than a release. Documented in full as SYS_008.
What was being built, and when.
- 2026.09
Contractor ERP
Designing project, labour, supplier and accounting workflows around the project as a cost centre.
- 2026.08
GasMitra
Gas agency operations: cylinder circulation, empty reconciliation, billing and outstanding.
- 2026.06
Logixmap
Fleet and tour operations with driver scheduling, trip expenses and proof workflow.
- 2026.03
VS Accounts
Extracted accounting into reusable infrastructure shared by every product instead of a ledger per system.
- 2026
Sceneway HMS
Hotel and restaurant operations ecosystem: rooms, POS, KOT, inventory, purchase, staff and accounts.
- 2025
Dairy System
Collection, quality-based rating and cycle payout for a milk collection operation.
- ONGOING
Lab
AI operators, graph permissions, offline-first architecture and a configurable workflow engine.
Varad Software builds practical custom business applications and ERP systems for operating companies — hotels, distributors, contractors, agencies and processors. The work is mostly the unglamorous kind: billing that has to be right, stock that has to reconcile, and accounts that have to close.
Most of the systems on this site were designed and built under Varad Software. The company builds them; this page is about how they are put together.
HAVE A SYSTEMTHAT NEEDS BUILDING?
The most useful first message describes the operation, not the technology — what happens at the counter, who has to approve it, and what currently goes wrong.