DEV Community: Spicanet

AI teammates that need your sign-off: building Protaura

Spicanet — Sat, 24 Oct 2026 03:31:57 +0000

The pitch for AI agents usually goes like this: describe your idea, go make a coffee, come back to a finished product. Then you come back to a confident paragraph, a broken demo and no idea what actually changed. Protaura is my attempt to build the less exciting, more useful version. A founder describes what to build, a small team of AI teammates does the work, and nothing is published without the founder's approval. It's in beta.

The problem with agent demos

Solo founders don't lack ideas. They lack hands. The promise of AI agents is extra hands, but most tools stop at narration: the agent tells you what it would do, or what it thinks it did, and you're left checking its homework with no trail to follow.

I wanted the opposite. Work that leaves evidence. Changes you can review as real changes, not as a demo. And a hard rule that the human stays in charge of what goes out.

The team

Teammate area	What it covers
Vision	What you're building and why
Project scope	What's in the first version and what isn't
Design and brand	How it looks and feels
Infrastructure and code	Making it real and running

Office and Mission Control

Work is split between the Office and Mission Control. The Office is where the teammates and their work live. Mission Control is where you see what's happening across a mission and where decisions wait for you.

Everything is recorded in an audit trail. When something changed, you can see what changed and who on the team changed it. That sounds like bureaucracy until the first time you need to know why a file looks different from yesterday.

A mission from idea to approved change

How work moves through Protaura.

You describe what you want to build.
The AI teammates split it into vision, scope, design and code work.
They do the work and record it in the audit trail.
Changes stop at an approval gate.
You review the real change, not a demo of it.
Only approved work is published.

An agent that tells you it succeeded is not evidence. A change you can open and reject is.

— the principle behind the approval gates

Approval gates are not friction

People sometimes ask whether approval gates slow things down. They do, a little, the same way code review slows things down. The alternative is finding out what your agents did after it's live, which is slower in every way that matters.

The gates also change how the agents' work gets shaped. If every change has to survive a human looking at it, the work has to be presented as something reviewable: a concrete change with context, not a wall of narration. That's a better product for the founder and, honestly, a better discipline for the software.

Plans, in general terms

The free plan runs the full mission and agent loop, not a crippled preview. You bring your own API keys, and you can import issues from GitHub so the team starts from work you've already written down. Paid tiers raise caps and add governance features. Current prices are on the site; I'd rather link than repeat numbers that may change.

Bring your own keys. Bring-your-own API keys on the free plan means you control the model account and its costs. It also means the free plan is genuinely usable, rather than a demo that runs out after a few clicks.

What's honestly still beta

Protaura is in beta and the portfolio lists it as active development. The agent loop works, but AI teammates are still AI: they'll misread scope, make design choices you don't like and write code that needs review. The approval gates aren't decoration. They're there because the work needs them.

I'm also not going to claim Protaura replaces a team. It's a way for one person to get more done with a clear record of what was done. That's a smaller claim, and I can actually stand behind it.

Before you hand work to any AI agent team

Make sure every change stops at an approval gate
Check there's an audit trail you can actually read
Review real changes and not summaries
Keep control of your own API keys
Start from written issues instead of a vague prompt

Note: Who it's for. Solo founders and small teams who want to move faster without giving up the final say. If you want a hands-off magic button, this isn't it, on purpose.

Take a look

Protaura is at protaura.com. The rest of my projects live on spicanet.net/products.

Originally published on spicanet.dev.

A record label told as a science-fiction story

Spicanet — Fri, 23 Oct 2026 16:34:12 +0000

Most label sites are a list of releases with cover art and buy links. That's fine. It's also forgettable. Universal Rift Records is an independent electronic music label where high-velocity drum & bass, hypnotic trance and mechanical techno converge, and the catalogue isn't just a list. It's a science-fiction world told in chapters, from first contact to the awakening of a machine supermind. The site is live, and this is how I think about building a label as a story.

Why a story at all

Electronic music already lives in sci-fi territory. The sounds, the titles, the artwork all lean toward space, machines and signals from somewhere else. Most labels gesture at that and move on. I wanted to commit to it: one world, one long arc, and every release a piece of it.

That gives the catalogue a shape. A release isn't just the next one in the list. It's the next chapter, and it belongs somewhere.

The sounds of one world

Sound	What it brings
Drum & bass	Velocity
Trance	Hypnosis
Techno	Machinery

The territories

The world is split into territories: Rift, Event Horizon, Starbirth and Signal. They give releases a place to belong, so a listener can follow a part of the world they like instead of scrolling a flat release list. I'm deliberately not spelling out every rule of each territory here. Some of that is for the music to do.

Chapters, not just releases

The story runs from first contact to the awakening of a machine supermind. Releases such as First Signal and Monolith sit inside that arc. The titles do some of the storytelling on their own, which is the point: you should be able to read the catalogue and feel the story moving even before you press play.

The sounds meet in this world. Drum & bass brings the velocity. Trance brings the hypnosis. Techno brings the machinery. They aren't kept in separate rooms; the territories are where they meet.

A catalogue should read like a story even before you press play.

â€” the idea behind the label

What the site holds

The site is the label's home base. It holds the catalogue, the artist roster, a video archive and a demo submission form. Nothing exotic, but each piece is shaped by the world: the catalogue reads as chapters, and the territories give each release a place.

Catalogue
Artist roster
Video archive
Demo submissions

The first release

The inaugural release is by Nocterion, and it's out on Bandcamp and the major streaming services. The label site doesn't try to replace those. It points at them, the same way a book's website points at where to buy the book.

Sending a demo. If you make drum & bass, trance or techno that sounds like it belongs in this world, there's a demo submission form on the site. Read a bit of the story first. It helps.

What I ask of every new release

Does it move the story forward or deepen a part of it?
Which territory does it belong to?
Do the title and artwork read as part of the same world?
Will it sit comfortably next to First Signal and Monolith?
Is it out where people actually listen?

What's honestly early

The label is young. With an inaugural release, the catalogue is at the beginning of its story, not the middle. That's how labels start, and I'd rather say so than dress it up with borrowed credibility.

The story is also a commitment. Once you tell people a world has rules, you have to keep them. Every future release has to fit, which is harder than just putting out the next good track.

If you're building a label site

Give the catalogue a shape and not just a list
Link out to where people actually listen and buy
Keep a video archive in one place
Make demo submission easy to find
Don't invent history the label doesn't have

Note: How it's built. In general terms: a content site with a structured catalogue of releases, artists and videos, each release tied to a place in the story, and outbound links to Bandcamp and streaming services for listening.

Have a listen

Universal Rift Records lives at universalrift.com. My other projects are on spicanet.net/products.

Originally published on spicanet.dev.

My money doesn't live in one country, so I built Nomad Flow

Spicanet — Wed, 21 Oct 2026 03:40:07 +0000

Every budgeting app I tried assumed I had one bank, one currency and one country. Cute. If you live across borders, your money is split between local accounts, a foreign bank, some cash in a drawer, some cards and maybe some crypto, and no app wants to see all of it at once. Nomad Flow is the app I wanted: a privacy-first personal finance tool for people whose money lives in more than one country, bank or currency. It's live on the web. The mobile story is more complicated, and I'll get to it.

The actual problem

The hard part of multi-country money isn't tracking spending. Any app can add up coffees. The hard part is answering a simple question: how much do I actually have, in one currency I can reason about, right now?

Most apps either force everything into one currency at the moment you enter it, which mangles history, or they don't handle foreign accounts at all. Then there are transfers between currencies, which many apps record as an expense in one place and income in another, and your net worth gets weird.

What you can put in it

Account type	How it's kept
Cash	In its own currency
Local bank accounts	In its own currency
Foreign bank accounts	In its own currency
Cards	In its own currency
Crypto	In its own currency
Loans	In its own currency

One net worth, many currencies

Yes, the right-hand column of that table is deliberately repetitive. That's the whole point. Every account keeps its own currency, and Nomad Flow shows one net worth in a reporting currency you choose. You don't have to pretend your local cash is secretly dollars.

Cross-currency transfers keep both legs. Moving money from one currency to another is recorded as what it is, a transfer with both sides, not as a mysterious expense followed by a mysterious income.

Money Chat proposes, you confirm

Data entry is where personal finance apps go to die. So there's Money Chat: you describe a transaction in plain language and it proposes a draft entry. It only proposes. Nothing lands in your ledger until you confirm it.

I'm firm about that rule. An assistant that writes directly into your financial records is an assistant that will eventually write something wrong into your financial records, and you won't notice until the numbers stop adding up.

The assistant drafts. The ledger is yours.

— the rule behind Money Chat

Planning without breaking anything

Plan expected income and spending.
Forecast your runway from what's actually in your accounts.
Test scenarios such as moving countries or losing a client.
Throw the scenario away. Your real ledger was never touched.

Privacy, in general terms

Financial data is about as personal as data gets. Sync between your devices is end-to-end encrypted, which is the part I'd look for first in any app like this. I'm not going to go deeper into infrastructure in a public post, and frankly you shouldn't trust a finance app that's eager to.

If you're coming from somewhere else, there's import from ZenMoney and from CSV, so you don't have to start your history from scratch.

Note: Why privacy-first. People who live across borders often have the most fragmented and sensitive financial picture: several banks, several tax contexts, sometimes a family spread over a few countries. That's exactly the data you don't want sitting in plain text on someone else's server. So privacy wasn't a feature to add later. It's the constraint the rest of the app is built around.

Free tier exists. There's a free plan and paid Nomad plans, monthly or yearly. Current prices are on the site; I'd rather link than copy numbers that may change.

The honest part: mobile

My portfolio lists Nomad Flow for web, iOS and Android, and marks it as active development. The web app is live. I haven't verified the store apps for this post, so I'm not going to tell you to go download them. If you're reading this hoping for a polished App Store listing, check the site first rather than taking my word for it.

Active development also means the app is still changing. Planning, forecasting and Money Chat are real and usable, but expect them to keep evolving.

Who it's for

You hold money in more than one currency
You have accounts in more than one country
You want one net worth figure you can trust
You care where your financial data goes
You prefer confirming entries over auto-import surprises

Try it if it fits

If your money lives in more than one place, Nomad Flow is at nomadflow.money. Everything else I'm building is on spicanet.net/products.

Originally published on spicanet.dev.

Build the engine, not the posts

Spicanet — Tue, 20 Oct 2026 14:32:00 +0000

Update (Oct 2026): CryptoCardCompass now lists 54 cards.

Around twenty of our own sites, one person deciding what they say. You can keep writing every page by hand and drown politely, or you can build the thing that writes, checks and ships them, and then spend your evenings arguing with it instead. The next months go into the second option: one typed content pipeline, one design language across the sites, and a fact-check gate that is allowed to say no. This is a roadmap, not a victory lap. The design work is out in the world. The engine and the gate are still being built and tested.

Why stop writing posts one by one

Every site started as its own small kingdom. Its own CMS habits, its own idea of what a guide looks like, its own way of being slightly wrong. Fixing one meant fixing it nineteen more times, usually by memory, usually at night.

The interesting work is not the next article. It is the machinery that knows what an article on this site is allowed to contain, where it gets its facts, and who has to look at it before it goes out.

Content gets a type and a schema, not a blank text box.
Every generated field should carry where it came from.
Publishing becomes a separate step with its own rules.
Live content gets refreshed instead of quietly rotting.

Writing the twentieth guide by hand is not craft. It is a cry for help with good grammar.

The roadmap, in order (in progress)

Typed content storage so a review is a review and a glossary term is a glossary term.
Generation directed by that schema and every field keeps its provenance.
A publication step that talks to our own CMS and to WordPress or custom sites through adapters.
Autopilot per content type, only where the type has earned it.
Refresh of live pages and follow-ups only after publication is verified.
One design language rolled across the sites so the engine is not dressing each one by hand.

Before and the plan for after

Site type	Before	Planned after
Guides and reviews	Hand-written per site	Typed content with sources attached
Glossaries and lessons	Copied structures that drift	One schema and many locales
Music and artist pages	Bios written from vibes	Bios that only keep supported claims
Design	Each site its own mood	Shared language with a local accent
Publishing	Whoever remembered last	An orchestrator with its own rules

The test case: artist bios that refuse to guess

DROP THE BASS is where the gate is being tested first. The artist bio pipeline we are building writes only bio fields and drops claims it cannot support. No invented residencies, no imaginary label history, no "legendary" unless something actually says so. It is not running in production yet. It is the place where we find out whether the gate is strict enough.

Spotify and YouTube matching by ID instead of by name is part of the same work. Plenty of artists share a name with someone who makes very different music, and matching by name is how a jungle producer ends up linked to a wedding band. An ID ends that argument.

The gate can say no

A fact-check that always passes is decoration. The bio gate we are testing drops unsupported lines and leaves the field shorter. A short true bio beats a long beautiful lie every single time.

One design language and many accents

This part is already out. VPNScoreLab, Brokeli, CoinFaro and ProxyLister got new design systems in the last weeks, and SpicaSEO got its own refresh. They should not look identical. They should feel like they come from the same workshop.

Brokeli now speaks eight languages, with calculators, lessons and a glossary. CoinFaro grew a real glossary and guides. That volume only makes sense if the engine underneath stays honest, which is exactly why the engine comes next.

Quality gates before anything goes live

Every factual field has a source the engine can point to.
Unsupported claims are dropped and not softened.
External profiles are matched by ID and not by name.
The page fits the site's design language.
Publication is verified before any follow-up runs.
A person can see what changed and roll it back.

What is honestly still in progress

The content engine in SpicaSEO and the new connector for our own CMS are in progress. Nothing here is shipped as a finished machine. Adapters come for our own CMS first, then WordPress and custom sites. Autopilot will be per content type and no type has earned it yet. The bio gate on DROP THE BASS is in testing, not in production.

A couple of new sites will grow up on this engine from day one. SpicaVPN is prelaunch with a waitlist. CryptoCardCompass is an early catalog with nothing published yet.

Every new site still gets a real review before it opens. The engine prepares. A person decides.

Why roadmap and not launch

We would rather publish where the engine is going and get corrected than announce a finished machine that still needs a babysitter. When pieces ship they go to the Friday Dev Log.

The bet

Fewer hand-made posts. More time on the engine and the gates. If it works, twenty sites stay honest with the same effort as two. If it does not, at least it fails loudly and in one place.

Originally published on the Spicanet blog: https://spicanet.dev/blog/build-the-engine-not-the-posts

Naming things is editorial work

Spicanet — Tue, 20 Oct 2026 14:24:00 +0000

Give a machine a pile of tracks and it will happily tell you what genre each one is. It will be fast, confident and wrong in ways that make a junglist want to throw a speaker out the window. Building a DnB and jungle genre taxonomy for DROP THE BASS taught us something we should have known already: naming things is not data cleanup. It is editorial work. Provider tags are hints. Every label needs a paper trail. The machine may propose. A person accepts. And when there is no evidence, the model does not get called at all.

Provider tags are hints, not truth

Streaming and event platforms come with genre tags. Some are good. Some are a marketing department's idea of DnB. Until recently an import could quietly overwrite a genre someone had chosen by hand, which is the data version of a stranger rearranging your record shelf while you sleep.

Now imports never wipe or overwrite genres, and a provider string never becomes a genre on its own. It gets read, interpreted and kept as a hint next to the real decision.

Imports from Spotify or RA cannot overwrite a chosen genre.
No new genre is created just because a provider typed a word.
Provider terms are interpreted, not obeyed.

A tag from a platform is a rumor with metadata. Treat it like a rumor.

Provider tag versus our decision

What a provider might say	Canonical genre	Decision
Liquid or liquid DnB	Liquid Funk	Restored as the canonical name
Ragga or reggae jungle	Ragga Jungle	Named properly and published
Footwork	Footwork	Kept hidden for now
Anything unknown	None	Stays a hint until a person decides

Every label carries a paper trail

Each genre on an artist, release or label now records where it came from. A human editor. A provider hint. A proposal from the engine that someone accepted. If a label is wrong you can see exactly how it got there, and fix the cause instead of the symptom.

The full taxonomy is visible on the genres page, so the decisions are public and arguable. That is the point. Names in a scene should be argued about by people who care, not settled by whichever API answered first.

How a label is allowed to happen

Propose: the classifier or the label engine suggests a genre.
Evidence: the suggestion must point to eligible first-party text written or approved by a person.
Review: an editor sees the proposal with its evidence.
Accept: only a person turns a proposal into a label.
No evidence means no proposal and no model call at all.

No evidence, no model call

The classifier is review-only and its switch is off by default. Only human-written or approved first-party text may reach a model. Spotify text is blocked in code. If nothing eligible exists the system makes zero model calls instead of guessing.

Start from the labels

Editors describe record labels. The engine then proposes genres for the artists and releases connected to them. Evidence is counted once per source so one loud page cannot vote ten times, and derived proposals never feed further guesses. Every proposal can be reviewed and rejected.

It is a small rule with a big effect: the machine can widen what an editor knows, but it cannot invent a chain of its own assumptions.

Before a machine may label anything

The evidence is first-party text a person wrote or approved.
The source is recorded on the label.
Provider tags are stored as hints and never as decisions.
A derived guess cannot become evidence for the next guess.
A person accepts or rejects every proposal.
There is a kill switch and it starts off.

The same rule outside music

Naming is one case of a wider habit: do not serve what is not true. VPNScoreLab stopped showing synthetic lab speeds. Its unpublished articles now actually return 404 instead of living on in cache. CoinFaro does the same for missing incidents with a real 404 and noindex rather than a cached page that says everything is fine.

A missing page that admits it is missing is more useful than a confident ghost.

A name like liquid funk is not a database value. It is a name a scene made, and we just have to write it down correctly.

Tell us

If we got a name wrong, we would rather hear it now than after the next import.

Originally published on the Spicanet blog: https://spicanet.dev/blog/naming-things-is-editorial-work

Handing a site over to software, honestly

Spicanet — Tue, 20 Oct 2026 14:23:41 +0000

Everyone wants a website that runs itself. Almost nobody wants to talk about what has to be true first. This is the plan for the next few weeks: what a site needs before software gets the keys, which jobs never go on auto no matter how good the software gets, and where we draw the line on AI faces and names. It is a roadmap, not a victory lap.

The keys are not the hard part

Turning on automation is one switch. Living with it is the hard part. A site on autopilot with no brief, no search data and no budget is not autonomous. It is just unsupervised.

So in SpicaSEO the switch now sits behind a hand-over checklist. Every item links straight to the screen where you fix it. Full Autopilot can only be turned on by the owner, and only after the list is done.

Before a site runs itself

The site connector works.
Publishing works end to end.
There is a written site brief.
The editorial team is set up.
A News section exists.
Search Console and Bing are connected.
There is a keyword strategy.
There is an AI budget.

What never goes on auto

Outreach stays on approval. Sending a message to a real person needs a real person to press send, and no checklist changes that.

Risk caps and the first-review rule still apply after hand-over. And every Monday the owner gets a digest of what the site did, so judging it is a habit and not an archaeology project.

Where the line sits

Job	On autopilot	Why
Drafting and publishing within caps	Yes after the checklist	Reversible and reviewed weekly
First pieces on a new site	No	First-review rule
Outreach to people	Never	Sending needs a person
Turning Full Autopilot on	Owner only	It is the owner's site

News without making things up

Each site now gets a daily news scan. Search answers are treated as leads, never as sources. Every cited page is actually fetched, and a story only counts if the quote is literally on that page. Stale or blocked sources get rejected.

It is slower than trusting a summary. It is also the difference between news and confident fiction.

How a story earns its place

A search answer suggests a lead.
Every cited page gets fetched.
The quote must appear on that exact page.
Stale or blocked sources are dropped.
Only then does it become a story.

AI faces, honest labels

Each site can have an AI editorial team, with roles taken from its brief. They can have portraits, and the portraits say what they are: an AI editorial persona, not a real person.

What they cannot have is a fake life. Invented credentials, employers and years of experience are refused. If a site has real people, they are imported read-only and never rewritten. Pictures come from free-licence libraries first, and generation is the fallback.

The hard line

An AI persona can have a face and a role. It cannot have a made-up degree or a made-up career.

Meanwhile across the fleet

The groundwork is already landing on our own sites.

Team and author pages plus news sections rolled out to ProxyLister, VPNScoreLab, CoinFaro, Brokeli, Samui Love, Trip2Fest and DROP THE BASS.
Several sites got redesigns from the new design canvas.
Zomia 1.0 left invite-only beta with open registration and an honest pricing page: no paid plans, fake tiers removed.
A shared platform update rolled across the repos.

A site that runs itself is only worth having if you can still read what it did on Monday morning.

Next weeks

Switch Autopilot on site by site, only after each checklist is done, and judge every one by its weekly digest.

Originally published on the Spicanet blog: https://spicanet.dev/blog/handing-a-site-over-to-software-honestly