Hi, I’m Melina. I focus on the infrastructure side of WeWeb — connecting projects to deployment pipelines and handling things that need to happen at build time rather than in the browser.
Two open-source tools I’ve built:
weweb-cloudflare-ci — CI/CD pipeline automating WeWeb deploys to Cloudflare Pages, with commit traceability and rollback visibility
weweb-dynamic-metadata — build-time generator for unique per-page SEO metadata on static exports, zero runtime overhead, works on any static host
I’d like to set either of these up on 1-2 real projects for free, mostly to test against setups beyond my own. If you’re dealing with deployment pain or missing/generic SEO metadata on dynamic pages, reply here or DM me and I’ll help you get it running.
Also open to collaborating on anything adjacent to this — deployment setups, build-time integrations, that kind of thing. Feel free to reach out even just to compare notes.
Hi Melina, thanks for sharing this. I’m currently building AfriFarmWork, an agricultural labour marketplace on WeWeb + Supabase. We’re still working toward MVP, so I don’t want to introduce unnecessary deployment complexity at this stage, but your dynamic metadata project caught my attention because we’ll eventually have public, data-driven job pages where unique SEO metadata could be valuable.
I’d be happy to connect and compare notes, and potentially explore whether AfriFarmWork could be a useful real-world test case when we reach that stage.
Thanks for the detail, and totally get holding off on extra complexity pre-MVP, that’s the right call.
AfriFarmWork sounds like a great fit for the metadata tool, job listings are basically the same shape as the article pages I built it for: unique, data-driven pages that need their own metadata rather than one generic tag for the whole site.
A couple of things that would help me gauge fit whenever you get there, no rush at all:
Are the job pages statically exported from WeWeb, or served dynamically through Supabase?
Roughly how many listings do you expect live at once?
If you can share more on what specific metadata those job pages would need (structured data for job postings, location/salary fields, anything beyond standard title/description tags), I’m happy to look at expanding the package to cover it properly rather than you having to work around gaps in what it currently supports.
Would also love to connect properly. Good luck with the MVP, and feel free to ping me whenever you’re closer to that metadata stage!
Thanks — this is really helpful, and I appreciate your willingness to look at expanding the package around the AfriFarmWork use case.
Our job pages are currently served dynamically. The job records sit in Supabase, and WeWeb retrieves the relevant listing dynamically using the job ID passed to the Job Details page, rather than us statically exporting a separate page for each job.
In terms of volume, we’re still pre-MVP, so I’d expect the initial live volume to be relatively modest — probably dozens to low hundreds of active listings at a time — but naturally we’re building with the intention of scaling beyond that as adoption grows.
For metadata, the ideal end state for us would probably include both the normal page-level SEO metadata and job-specific structured data. In particular:
• Job title and description
• Canonical URL
• Location — state/LGA and potentially more detailed location where available
• Salary/wage amount and wage period
• Employment type
• Date posted
• Application deadline / valid-through date
• Hiring organisation/farm information
• Job identifier
• Open Graph/social sharing metadata
• Schema.org JobPosting structured data
The structured job data is probably the part I’m most interested in, because if the metadata layer can understand the Supabase record behind each dynamic WeWeb page, it could save us from having to create a separate SEO workaround later.
We’re deliberately keeping the MVP lean at the moment, but I’d definitely like to stay connected as we move towards this stage. I’m also happy for AfriFarmWork to be a useful real-world test case if you decide to extend the package for dynamic job-listing sites.
Thanks again, Melina — and yes, would be great to connect properly.
On the architecture: my package currently works at build time, generating static HTML files with baked-in metadata ahead of time. Since your job pages are served dynamically from Supabase rather than statically exported per job, that won’t map 1:1 onto your setup as-is. What I’m planning is to extend it into a webhook-triggered tool instead, so metadata gets generated or updated whenever a Supabase record changes, rather than requiring a full rebuild. That should fit your setup much better, and still comfortably handle the volume you mentioned.
On the metadata itself, I’ll look into expanding the generator to cover the structured data you listed, especially the Schema.org JobPosting piece, alongside the OG tags and standard SEO fields. Since the goal is for the metadata layer to actually understand the Supabase record behind each page, that lines up well with the webhook-based direction anyway.
I’ll keep you posted as I work through this, and would love to check back in once I have something closer to testable. Thanks again for laying this out so clearly, really useful to build against.
This sounds excellent — and the webhook-triggered direction makes a lot of sense for our setup.
Having the metadata respond to changes in the underlying Supabase job record feels much more natural for AfriFarmWork than trying to fit our dynamic pages into a build-time/static workflow. The JobPosting structured data alongside the standard SEO and OG metadata would also cover exactly what we would eventually need.
I’d be very happy for AfriFarmWork to serve as a real-world test case as you develop this further. When you have something closer to testable, feel free to reach out and we can look at how it fits against our actual Supabase/WeWeb setup.
I’ll already requested connect with you on LinkedIn as well. Name is Emeka Obiaku.
Thanks again, Melina. Really interested to see where you take this.