Proposal for a Governed Digital Platform | Butwal Power Company Limited
Proposal to modernize BPC's Joomla website into a governed corporate disclosure and information platform
Prepared by: Aashik Baruwal and Amit KC
Date: August 22, 2026
Proposal validity: To be agreed during initial discussions
Primary contact: Aashik Baruwal
Portfolio: https://aashikbaruwal.com.np
1. Executive proposal
Butwal Power Company Limited being a NEPSE-listed power company whose website is an important channel for shareholder communications, statutory notices, financial reports, regulatory disclosures, project information, and public procurement information.
BPC's current public website is Joomla-based. Joomla can support general publishing, but it does not by itself provide the governance controls expected for a listed company: structured disclosure workflows, separation of duties, controlled publication, reliable document history, and an auditable record of who prepared, reviewed, approved, and published each item.
We propose to design and implement a custom, BPC digital platform that fully replaces the current Joomla website. The new Next.js platform would not depend on, interlink with, or run alongside Joomla after production cutover. It would combine:
- A modern, fast, bilingual public website for shareholders, regulators, bidders, lenders, employees, and the public.
- A secure administrative console for preparing, reviewing, approving, publishing, and archiving BPC content.
- Governed maker-checker-approver workflows for notices, financial reports, and regulatory disclosures.
- Structured repositories for notices, financial reports, regulatory documents, projects, tenders, and other corporate records.
- Module-specific controls for projects, compliance risks, generation records, and sealed bid submissions.
- Tamper-evident audit evidence for defined governance, publication, access, and procurement events.
The result would be a single digital system for BPC's public information and controlled publishing processes, with a clearer and more accountable operating model.
This proposal is based on a working prototype. The production platform would be configured, branded, secured, and expanded specifically for BPC after a short discovery and requirements phase.
2. Proposed outcomes for BPC
The proposed platform is intended to help BPC:
- Publish market-sensitive notices and reports through a controlled approval process.
- Maintain consistent Nepali and English versions of the same disclosure.
- Give authorized staff clear, role-based access instead of relying on broad CMS administrator privileges.
- Maintain an organized, searchable archive of current and historical corporate documents.
- Preserve defined evidence of review, approval, publication, document access, and procurement activity for internal audit and regulatory review.
- Present BPC's projects, operations, announcements, and procurement information through a professional public interface.
- Add a secure procurement and tender workflow where BPC requires it, including controlled bid handling and opening procedures.
The platform would support BPC's compliance obligations. It would not replace the legal, regulatory, or company-secretarial judgment required for each disclosure.
3. Proposed platform
3.1 Public website
The public website would provide a modern information architecture for:
- Company profile, leadership, governance, and investor information
- Notices, announcements, AGM information, dividends, and book closures
- Quarterly and annual financial reports
- Regulatory and material disclosures
- Project and asset information
- Procurement notices, tender documents, and supplier information
- Contact information, downloads, and searchable archives
Content would be stored as structured records rather than isolated page edits. Nepali and English content could be maintained together, with publication status and revision history visible to authorized staff.
3.2 Secure administrative console
The administrative console would provide controlled access for the teams responsible for communications, company secretarial work, finance, legal review, information management, procurement, and administration.
For notices, financial reports, and regulatory disclosures, the proposed workflow is:
Architecture Diagram
The production roles would be based on the prototype's CONTENT_EDITOR, COMPLIANCE_VIEWER, and SUPER_ADMIN responsibilities. The system would enforce independent review for the governed modules so that preparation, recommendation, and final approval are not treated as one unrestricted action. Publication may be immediate or scheduled, depending on BPC's process.
Other modules use controls appropriate to their purpose rather than being forced into the same workflow. Projects use direct publication controls, risk items track compliance status, published generation logs are immutable, and financial bid envelopes remain sealed until their authorized opening date.
3.3 Disclosure and document management
The platform would organize BPC's documents by type, fiscal year, language, subject, project, and publication status. Authorized users would be able to:
- Create and review notices and reports
- Attach verified documents and supporting records
- Maintain Nepali and English versions
- Schedule or authorize publication
- Archive or replace older published records while retaining the applicable audit history
- Search and export an organized disclosure archive
3.4 Procurement and tender capability
The proposed tender module would provide:
- Tender notice and document publication
- Bidder submission tracking
- Role-controlled access to technical and financial submissions
- Declared opening dates and committee actions
- Audit records for receipt, access, opening, and download events
The financial-envelope workflow would use client-side AES-256-GCM encryption so that the server stores ciphertext and cannot read the financial proposal before the authorized opening process. The bidder-generated key must be retained and presented through the approved procedure; a lost key is unrecoverable by design. The final operating procedure would be confirmed with BPC's procurement and legal teams.
3.5 Audit and security controls
The proposed production build would include:
- Multi-factor authentication for administrative users
- Role-based permissions and database-enforced BPC deployment boundaries
- A single-BPC deployment in which
tenant_idis retained only as an additional defense-in-depth security layer, not as a multi-tenant product feature - AAL2 multi-factor authentication, single-session controls, and a 15-minute administrative inactivity timeout
- File integrity checks for uploaded documents
- A cryptographically linked canonical ledger for defined governance events, supported by separate mutation, access, and bid audit records
- Cloudflare edge protection, rate limiting, and web application security controls
- Automated backups according to the selected production plan, documented restore procedures, and recovery testing
These controls are intended to make the platform easier to govern and audit. Final controls, retention periods, and operating procedures would be approved with BPC during discovery.
4. Why a custom platform
The objective is not only to change the visual design of BPC's website. A custom platform would give BPC a controlled information system that matches its internal responsibilities and listed-company obligations.
| Requirement | Joomla-based publishing | Proposed BPC platform |
|---|---|---|
| Public corporate information | Pages and media uploads | Structured content and searchable records |
| Disclosure approval | Dependent on CMS configuration and staff procedure | System-enforced states for notices, reports, and disclosures |
| Separation of duties | Requires manual discipline | Role and database controls for governed records |
| Document history | May require manual reconstruction | Structured publication, archive, checksum, and audit metadata |
| Bilingual content | Separate pages or uploads | Linked Nepali and English records |
| Sensitive procurement | Not currently available as a bid portal | Optional controlled tender workflow |
| Audit evidence | Distributed across systems | Cryptographic governance ledger plus controlled mutation, access, and bid records |
5. Working prototype
The following links demonstrate the direction of the proposed platform. They are prototypes, not BPC's production system:
- Governance portal: https://archhydroservice.workwithaa-sik.workers.dev/
- Additional prototype and portfolio work: https://www.aashikbaruwal.com.np/arc-and-civ
The prototype illustrates the type of administrative and public-facing experience that can be adapted to BPC's branding, roles, workflows, content model, and security requirements.
6. Delivery approach
The expected initial implementation period is 10-12 weeks after scope, access, and responsibilities are agreed.
Architecture Diagram
Phase 1: Discovery and scope
Confirm BPC's disclosure obligations, internal roles, approval rules, content categories, retention requirements, domain strategy, and integration needs.
Phase 2: Design and configuration
Apply BPC branding, configure the public information architecture, create administrative roles, and configure disclosure and document workflows.
Phase 3: Migration and implementation
Migrate the agreed Joomla content, documents, metadata, and URLs into the new platform, then prepare the production infrastructure, storage, backups, redirects, and security controls.
Phase 4: Testing and training
Run role-based user acceptance testing, security checks, publication rehearsals, and staff training.
Phase 5: Launch and handover
Deploy the approved Next.js platform as BPC's new website, complete the domain cutover from Joomla, and provide documentation and operational handover.
7. Scope assumptions
- BPC will nominate authorized representatives from management, company secretarial, finance, legal, IT, and procurement as relevant.
- BPC will confirm the content, records, policies, and regulatory procedures that must be migrated or implemented.
- The production platform will be a single-BPC deployment; its internal
tenant_idboundary is an additional security control rather than a shared-customer hosting model. - Final integrations, migration volume, hosting ownership, retention periods, and support arrangements will be agreed during discovery.
- The listed technical controls are proposed production commitments, subject to final architecture and security review.
- Commercial pricing and payment milestones will be submitted after the discovery scope is agreed.
8. Technical foundation
The proposed implementation can use the following production stack, subject to BPC's review:
| Area | Proposed approach |
|---|---|
| Application | Next.js, React, TypeScript, and responsive design |
| Delivery | Cloudflare Workers and edge delivery |
| Database | Supabase PostgreSQL with Row-Level Security |
| Identity | Supabase Auth with multi-factor authentication |
| File storage | Cloudflare R2 with integrity metadata and access controls |
| State and rate limiting | Upstash Redis where required |
| Audit | Canonical cryptographic governance ledger with separate mutation, access, and bid audit records |
| Sensitive bids | Client-side AES-256-GCM encryption with sealed opening-date enforcement |
9. Estimated infrastructure budget (USD)
Infrastructure would be provisioned under BPC's corporate accounts so that BPC retains ownership of the hosting environment, data, and billing. The following figures are conservative planning estimates based on the proposed Cloudflare-first architecture. They are separate from implementation, maintenance, support, domain, and professional service fees.
What the infrastructure services do
The platform would use several managed cloud services. In simple terms:
| Service | What it does for BPC |
|---|---|
| Cloudflare Workers | The application engine. When a shareholder opens the website, downloads a report, or an authorized staff member uses the administrative console, a Worker processes that request and returns the correct page or result. BPC does not need to operate a physical web server. |
| Cloudflare R2 | The document store. It holds annual reports, notices, tender files, images, and other website documents. |
| Cloudflare KV | A fast temporary memory layer. It keeps frequently requested information ready so the system can respond quickly during high-traffic announcements. |
| Database | The organized record system for pages, disclosures, users, approvals, projects, and publication history. |
How the monthly bill is calculated
The monthly bill is calculated like a utility bill:
Monthly bill = fixed base plan + usage above included allowances + any optional services.
The fixed base plan is the minimum monthly charge. Additional charges apply only when usage goes beyond the allowances included in the selected plans. The main usage measures are:
- Requests: Each time the website or administrative console asks the application engine to do something.
- Document operations: Actions such as reading or downloading a stored PDF or image.
- Cache reads: Requests to retrieve information from the fast temporary memory layer.
- Storage: The total volume of documents kept in the system.
For example, if a shareholder opens a quarterly report, the platform uses one or more application requests, retrieves the document from storage, and may serve commonly requested information from the cache. The provider measures those activities in aggregate for the month and applies overage rates only where the included allowance has been exceeded.
Base monthly cost
During a quiet month, the expected fixed platform cost is approximately $5.00 per month:
| Service | Planning allowance |
|---|---|
| Cloudflare Workers Paid Plan | $5.00 |
| Cloudflare R2 storage allowance | $0.00 within the assumed allowance |
| Cloudflare KV allowance | $0.00 within the assumed allowance |
| Database and text data | $0.00 within the assumed allowance |
| Estimated base total | $5.00 / month |
Peak traffic planning scenario
The platform is expected to experience its highest public traffic around dividend announcements, annual and quarterly reports, AGM notices, and major tender publications. For planning purposes, the following scenario assumes usage beyond the included allowances:
| Usage assumption | Estimated additional cost |
|---|---|
| 15 million Workers requests, including 5 million over the assumed allowance | $1.50 |
| 12 million document downloads, including 2 million over the assumed allowance | $0.72 |
| 20 million KV reads, including 10 million over the assumed allowance | $5.00 |
| 20 GB archived documents, including 10 GB over the assumed allowance | $0.15 |
| Illustrative peak-month total | Approximately $12.37 / month |
The calculation behind this example is:
- $5.00 base plan
- +$1.50 for 5 million additional application requests
- +$0.72 for 2 million additional document operations
- +$5.00 for 10 million additional cache reads
- +$0.15 for 10 GB of additional storage
- =$12.37 estimated peak-month infrastructure cost
This is an illustration of how the bill is built, not a promise that every peak month will cost exactly $12.37.
Budget range for management planning
| Usage level | Estimated monthly cost (USD) | Planning description |
|---|---|---|
| Normal month | $5.00 | Standard daily traffic, document publishing, and normal report viewing |
| Peak or AGM month | $10.00-$15.00 | Heavy report downloads, disclosure activity, and tender traffic |
| Extreme traffic scenario | Up to approximately $20.00 | Exceptional traffic beyond the assumptions above |
These figures are estimates for budgeting, not a fixed-price hosting guarantee. Actual charges depend on the selected service plans, storage volume, request volume, database tier, backups, monitoring, email delivery, taxes, and provider pricing at the time of deployment. Before go-live, we would confirm the final account configuration and provide BPC with an updated usage budget and billing controls.
The edge delivery and caching design is intended to absorb sudden public traffic increases without requiring BPC to operate physical servers. BPC would see a small usage-based increase rather than needing to purchase additional hardware for an announcement or tender event. Availability and cost remain subject to provider terms, account configuration, and normal operational safeguards.
10. Our team
The proposal is submitted by two developers:
- Aashik Baruwal, Full Stack Developer, responsible for product development, application architecture, and delivery coordination.
Portfolio: https://aashikbaruwal.com.np
- Amit KC, Software Engineer, with experience working with international clients and contributing to software delivery and engineering quality.
LinkedIn: https://www.linkedin.com/in/mraalu/
We would work directly with BPC's nominated stakeholders and provide a documented handover at the end of implementation.
11. Recommended next step
We request a 30–45 minute introductory meeting with the appropriate BPC representatives. The meeting would allow us to:
- Demonstrate the working prototype.
- Understand BPC's current publishing, approval, archive, and procurement processes.
- Confirm the content, URL structure, redirects, documents, and other requirements for a complete migration from the existing Joomla website to the new platform.
- Prepare a final migration scope, implementation plan, and commercial proposal.
12. Closing
We believe BPC's public digital presence should reflect the standards expected of a listed power company: clear information, controlled publication, reliable records, and accountable governance.
We would welcome the opportunity to present the prototype and discuss how a purpose-built platform could be tailored to Butwal Power Company Limited.
Submitted by Aashik Baruwal and Amit KC
Portfolio: https://aashikbaruwal.com.np