Case study · ONE MPRL Solar Power
ONE MPRL publishes its own content, with no developer in the loop
A solar provider expanding out of Bicol into Metro Manila and CALABARZON needed a site that read like an established company and a way to keep it current without booking developer time for every announcement.
Snapshot
| Client | ONE MPRL Solar Power Corporation, solar installation |
| Market | Bicol, expanding into Metro Manila and CALABARZON |
| Built | Corporate site with an administered content section |
| Stack | Laravel, Vue, Inertia, Tailwind CSS, MySQL |
| Timeline | June 2024 to February 2025, team of three |
| Content types their staff maintain | 5 |
| Publishing | Was a hired graphic designer. Now a Facebook post the site mirrors. |
The Challenge
A regional installer moving into two new markets is judged against established competitors before anyone picks up a phone. Two problems follow.
- The site had to carry weight the company already had. Buyers evaluating a capital purchase read a website as evidence of whether the company will still exist for the warranty period.
- Every announcement went through a hired graphic designer. Their publishing habit was Facebook, and posting to it meant commissioning artwork first. That is a cost and a delay per post, and it is why the things worth announcing often were not.
- Enquiries arrived as email, or not at all. A buyer with a question at the moment they are interested will not compose an email about it.
If publishing an update to your own channels involves paying someone first, you already know this one.
The Approach
An application, not a brochure. Products carry categories, specifications and downloadable datasheets. Projects carry galleries. Enquiries are captured and reviewed. That is application behaviour, so the site was built as one, on Laravel with Vue over Inertia, rather than split between a static generator and a hosted content service that would have meant maintaining two systems for one website.
Five content types, modelled separately. Blog posts, products, services, projects and frequently asked questions each have their own model, screens and validation. The alternative was one generic page type with flexible fields, which is faster to build and pushes all the structure into free text. A product would have lost its datasheet field and its target URL, and nothing would have stopped someone publishing a product with no price.
For the client that means the admin screens ask for what each thing actually needs, which is what makes a non-technical person able to use them unsupervised.
The site meets them where they already publish. Rather than asking staff to learn a second publishing habit, the site mirrors their Facebook posts. They post once, to the audience they already have, and the site carries it. That removes the graphic designer from the loop for anything that is an announcement rather than a campaign.
Enquiries are a conversation, not a form. A chat channel on the site lets a prospective buyer ask a question at the moment they have it, and product datasheets are sent through that channel when someone starts a conversation. A contact form collects an address; a chat window collects the question, which is the thing a salesperson actually needs.
The Build
Three developers over eight months, working through pull requests. My share was the content models and their relationships, the administrative dashboard and tables, pagination and image handling, authentication, and the homepage.
Where it went wrong: file upload. The pull request history has a two-week run in late August and early September 2024 that is almost entirely corrections to product image handling, one of them describing the product editor as unstable specifically around images. Replace-an-existing-image is the case that broke: creating a record with an image and editing a record that already has one are different operations, and treating them as one produced a form that lost images on save.
It took roughly two weeks of fixes to settle, and it was the least stable part of the build by a wide margin. Upload with edit semantics is where I would now spend design time first rather than treat as a form field.
A revision pass, four months later. Between November 2024 and February 2025 the services, products, about and contact pages were revised. Corporate sites are not finished at launch; they are finished when the client has seen theirs next to a competitor's.
Results
| Before | After | |
|---|---|---|
| Publishing an announcement | Commission a graphic designer | Post to Facebook, the site mirrors it |
| Product datasheets | On request | Sent through the chat channel on first contact |
| Enquiries | Email, or nothing | A conversation started on the page |
| Content types staff control | 0 | 5 |
The site is the client's to run. What I cannot tell you is what that changed commercially: traffic, enquiry volume and publishing frequency were never reported back to me, and inventing them would be worse than leaving them out.
Next
If publishing to your own site costs more than publishing to your Facebook page, the site is the thing that is wrong. Get in touch.