Where I come from
Ten years as a full stack developer, tech lead and designer, on an artistic background and a broad knowledge of the art world, web3 and cultural management. Wide professional experience in the technology layer of industries such as IoT, toll management and construction.
Working as a software developer I was always the kind who is more interested in defining and designing the solution than in implementing it. Deciding what was worth building, and why, was what mattered most to me. Which is why I usually worked close to the product owners.
Now that the agents have taken over almost all of the implementation, and almost all of the problem solving, pivoting towards product design is the natural progression for me.
juanmamoreno.com, the product definition
The core of the application is a catalogue of artwork. The catalogue consists of a number of pieces which are, at the same time, their own certificate of authenticity. The authenticity of each piece is guaranteed by the fact that every one of them is minted on the Ethereum blockchain with a contract only the author of the works holds the key to. The information in the catalogue — the certificates of authenticity — is therefore immutable and independent of the app.
So the catalogue is visible and navigable by any user or agent, while the tools that manage it can only be used by the artist, who is at the same time the site’s only administrator.
The app lets the administrator manage the catalogue — mint new certificates on the blockchain, mark a work sold or available — automates posts to several social networks as image and as video, and makes it easy to edit the photographs of the certificates without depending on an external tool. Alongside that there are a number of automated tasks: writing the descriptive texts, the periodic reverse image search across the web, and generating PDFs such as dossiers, technical sheets and certificates of authenticity.
The site is optimised to be found by AI agents, and includes a small MCP for reading the catalogue data, whose connector the author uses in various automated flows with Claude Cowork — finding opportunities that fit the catalogue, for instance.
The site is static in the strict sense. Every page, in both languages, is written to disk before it is published and served as a file: there is no server rendering anything, and therefore no server to fall over, to patch or to pay for. The whole system is designed for the cost to be minimal — a couple of euros a month, roughly.
The cloud architecture is, in essence, a service serving an API, a number of cloud AI services (for reverse image searches across the internet, and for generating texts from images and descriptions), a database for the app’s information and the cache of the certificates, and a bucket for the high-resolution images and the videos.
Outside the scope of the cloud and the frontend app sit the on-chain data (the certificates and the contract) and the permanent distributed storage of the web-resolution images.
Product description
Three things: certificates of authenticity, catalogue, and a toolbox for the artist.
Certificates of authenticity
Each physical work corresponds to N NFTs, written on a public blockchain (Ethereum). Each NFT holds the work’s metadata, along with a thumbnail (2kb) in base64 and links to a web-resolution image on distributed storage and to a high-resolution image held in a cloud bucket. The NFTs — certificates of authenticity from here on — are minted by a contract the artist owns and only he can sign. With no intermediaries and no dependencies, the artist-admin owns the whole chain. This infrastructure is designed with one main aim: to be independent and immutable, and to outlive this app and even the author himself.
That work’s certificate of authenticity ↗ The catalogue
On top of this collection of certificates, a number of features have been built so that any user can browse the catalogue, search, filter, download certificates and technical sheets as PDFs, run reverse image searches across the web, check whether a work is available for sale, get in touch with the artist, ask for a quote…
Here the main challenge is performance. For that, the on-chain data is cached and the images load in succession from lowest to highest resolution, so that browsing is quick even while loading images that in some cases are over 10MB.
The catalogue, with its filters ↗ Toolbox for the artist
Every week’s work, automated: edit the photograph of a painting, crop it to the frame, take the glare off, adjust the levels, then write and translate a short essay, add the work to the on-chain catalogue and publish the images and the video generated for it to social networks. All of it is automated so that human intervention is as small as possible and the artist can concentrate on what matters, which is the work in the studio and not the management of it.
The page the catalogue is managed from, behind a sign-in
Keeping control
The solution delegates the implementation, as well as the test and deployment pipelines, to AI agents. The flow is automated: the product owner puts requirements to the agent, and the agent implements them, runs the unit tests and the e2e tests, makes sure the pre-existing requirements still hold, and only then deploys the frontend and the services and releases a new version.
In my opinion, keeping control of the requirements — of their permanence, and of how they have been implemented — is the main risk we take on when we delegate to agents. So this work has been channelled along the following lines:
REQUIREMENTS DOCUMENT: a requirements document is a statement about the present. The truth of those statements is tested by naming what proves them. A script reads the file before every deploy and refuses the build if a number is used twice, if an entry has no test, if a test names a deleted file, or if it cites a test that has been renamed.
It is also the reference document for the app’s requirements whose only proof is the text itself — since this is a one-person project, any Agile task-management tool has been dispensed with entirely; here it reads as redundant.
AGENTS: a guidance document for language models that sets limits and states a preference about how to work. The idea is not to delegate one hundred per cent of the sensitive decisions about architecture, design, development practices or writing tests.
Agents and crawlers
Every page is written to disk before it is published, the text is in the HTML and nothing has to run to read it; each work carries its structured data; and the file that governs crawlers names the language models’ own crawlers one by one and lets them in.
The whole catalogue is published as a single json file as well: title, year, medium, measurements…, the text in both languages, the image, both addresses of the page and the certificate token. The build writes it from the pages themselves, so it cannot contradict them, and the build refuses to publish if the file stops matching what was built.
The service speaks the MCP protocol at backend.juanmamoreno.com/mcp, for anyone who wants to widen their agent’s context with the catalogue’s information. Realistically, the only use of the MCP so far is widening the context of my own agents, so that the processes I automate day to day can work with a wider context and spend fewer tokens.
LINKS
The service behind the catalogue lives in a private repository and, deliberately, is neither linked nor described here, for security.