ProdLocales
Local product pricing and analytics
A product experiment about local prices, built end to end.
A web application built to explore how local product pricing could be collected, organised and analysed. The experiment was built and worked; development is currently paused.
- Source code — link not available yet
- Application — link not available yet
Repository and documentation links are not public yet.
Status
Development is currently paused.
ProdLocales was built as a working experiment, not a spec. It is not being developed at the moment, and the hosted database behind it pauses automatically after a period of inactivity — platform behaviour, not a failure of the project. No reason for the pause is documented, so none is invented: development is currently paused.
The problem
Prices exist everywhere; understanding them locally is the hard part.
ProdLocales started from a question about local commerce: what does something actually cost around here, and how does that change over time? Price information for everyday products exists in fragments — on shelves, in flyers, in shops’ own channels — and there is rarely a single place where it can be compared or analysed.
The product was designed for that gap: take information about products and their local prices, organise it, and turn it into analysis a person could act on.
This is the problem the experiment was designed around. ProdLocales never reached real users, so there is no market validation to report — and this page does not claim any.
That was the question the experiment set out to explore, and the point at which it stopped when development was paused.
A product, not a spreadsheet.
The idea was to turn scattered price information into a product: structured product data, organised locally, analysed over time, and presented as information someone could act on.
ProdLocales was built as a web application with its own data layer, so the workflow could exist as software rather than as a manual process.
Product information
Local pricing data
Analysis
Insights
Decision
This page documents the project at the level of its design. The source has not been published, so finer implementation detail is deliberately not described.
How it worked
A user entered information; the product returned organised, analysed pricing data.
User
Interacted with the product through the web interface.
Input
Products and their local pricing information were registered in the application.
Storage
The data lived in the hosted Supabase database the application was built on.
Processing
The application organised the stored information so it could be compared and analysed.
Result
The user saw pricing information presented as analysis rather than as a raw list.
The stages describe the product at the level of its design. Because the source is unpublished, this page does not go deeper than what is documented.
Architecture
The system as it was designed: a web application on a hosted database.
Client
- User
- Web interface
ProdLocales application
- Product data
- Pricing records
- Analysis
- Presentation
Hosted data (external)
- Supabase database
ProdLocales was designed as a web application on top of a hosted Supabase database. The diagram describes how the system was built — it is not a statement about current operation. With the project paused, the hosted database pauses automatically after a period of inactivity; that is platform behaviour, not an infrastructure failure.
Technical decisions
Decisions that are documented at the level of the project’s design.
A managed data layer from day one
The application was built directly on a hosted Supabase database instead of a self-managed backend service.
- Why
- For a one-person experiment, managed hosting removed an entire category of infrastructure work that produced no learning on its own.
- Consequence
- The product could be built end to end quickly — and the same managed hosting pauses automatically when the project is inactive, which is exactly what happened.
Product thinking before tooling
The starting point was who would use the product and what information they needed, not a framework.
- Why
- The experiment existed to explore a real question about local pricing, and every technical choice was in service of that question.
- Consequence
- The project stayed small and oriented around the data it existed to organise — and its limits were discovered earlier than they would have been behind more infrastructure.
Structure over raw data
Products and prices were modelled as structured records so analysis was possible at all.
- Why
- Comparing and analysing prices requires data with shape, not a list of unstructured entries.
- Consequence
- The application could organise and present pricing information as analysis rather than as storage, which was the core of the product idea.
From data to information
What the product did with the information a user entered.
Data
Products and their local prices, as entered.
Organisation
Records given structure in the data layer.
Analysis
Information prepared for comparison over time.
Presentation
Analysis shown in the interface.
Decision
What the user was meant to take away.
The application sat between raw entries and the analysis the user saw.
The product’s value was intended to be this transformation. The page documents it at design level because the source has not been published.
Current state
What exists, what is paused, and what is simply not public.
Built
A complete product experiment
A web application with its own data layer, built end to end around local product pricing.
Product and pricing data model
Products and their local prices modelled as structured records.
Analysis and presentation
Stored information organised and shown in the interface as analysis.
Design-level documentation
The problem, idea and architecture described here, at the level of the project’s design.
Paused
Development
Development is currently paused. The project is not declared abandoned or failed — it is stopped, and that is the whole statement.
Hosted database
The hosted Supabase database pauses automatically after a period of inactivity. This is platform behaviour, not a product or infrastructure failure.
Not published
Repository and source
The source has not been published, so this page describes the project at design level and makes no deeper implementation claims.
Hosted application
The application is not publicly reachable, so there is no live link to it here.
Roadmap
No future plan is documented for the project, so none is presented. Any future step would start from resuming development.
ProdLocales was built as a working experiment. Paused is not failed, and unpublished is not vanished: the project and its code remain, simply not public.
What building it taught me
Building ProdLocales taught me that a product and a feature are not the same size of problem.
The technical work — a web application with a real data layer — turned out to be the smaller half. The larger half was product thinking: deciding what information mattered, what the user needed to see, and what the product was for. It also taught the discipline of stopping: recognising when an experiment has taught what it had to teach, and pausing it deliberately instead of letting it drift.
- product thinking
- real-world problem modelling
- data modelling
- web application architecture
- frontend and data-layer integration
- product requirements
- scoping an experiment
- deciding to pause
A finished experiment that teaches its lesson is not a failure — it is evidence.
A project can be paused and still be valuable.
ProdLocales was built, it worked, and it taught what it had to teach. Development is currently paused; what remains is a completed product experiment and what it proved.
- Source code — link not available yet
- Application — link not available yet
The repository and the hosted application are not public.