About

Who built this

One person. A software developer who got interested in browser automation and web scraping a couple of years ago, found the existing tools either too low-level or too constrained, and started building the thing he actually wanted to use. That project became Guida.

There is no company behind this. No startup, no team, no investors, no advisory board. The decisions — architectural, ethical, commercial — are made by the person writing this sentence. That’s a limitation in some obvious ways and a feature in others. It means the project can be honest about trade-offs without filtering them through a marketing department. It also means the bus factor is one.

The unsigned binary

If you downloaded Guida and Windows showed you a SmartScreen warning, that’s expected. The binary is not signed.

Code signing certificates require either an organization with verifiable legal identity or an extended validation process that costs several hundred dollars per year and assumes a corporate structure. A solo developer shipping free software doesn’t fit neatly into that model. The certificate would cost more than the project earns, which is nothing.

The SmartScreen warning doesn’t mean the software is malicious. It means Microsoft hasn’t seen enough installations to build a reputation score, and no certificate authority has vouched for the publisher’s identity. When you click “Run anyway,” you’re telling Windows that you’ve made a conscious decision to trust this specific binary. That’s a reasonable thing to do — or not do — depending on your own risk tolerance.

Source boundaries

Guida currently ships as a closed-source Windows app. The product-specific browser automation and web scraping layer will stay closed source.

That boundary is deliberate. The scraping layer is the part most tied to Guida as a product, and it is also the part where convenient redistribution of modified builds could remove guardrails from the highest-risk capability.

The reusable infrastructure built around it is different. The scripting engine, secrets management, auditing, and related support code will be open-sourced once they are extracted, stable, and documented enough to be useful outside the app. I am not publishing a date yet because that extraction boundary still has to be made clean, but the direction is intentional.

See Source Boundaries for the fuller breakdown.

Infrastructure built for Guida

Some infrastructure created while building Guida is already public:

• JanetSharp — Janet runtime integration for .NET.
• StratQueue — SQLite-backed work queues with pluggable dequeue strategies.

What Guida is not

Guida is not a company. There is no roadmap driven by market research, no feature prioritization based on user surveys, no growth metrics. There is no support contract and no SLA. If something breaks, it gets fixed because the developer uses the software and noticed, or because someone reported it and the fix was straightforward.

It’s a tool that exists because it was worth building, maintained by the person who built it, used by people who find it useful. That’s the entire business model, minus the business.

An open question

Guida includes g.tts.speak() — local text-to-speech via Microsoft’s built-in TTS engine. Whisper-based voice input is in progress. Neither of these was built as an accessibility feature, and I’m not going to frame them as one after the fact.

But here’s what I notice. The direction Guida is heading — an LLM-driven agent that navigates arbitrary web UI through vision, speaks what it sees, and listens for what to do next — is a fundamentally different kind of tool than a DOM-based screen reader. It doesn’t parse ARIA labels or walk the accessibility tree. It looks at the screen the way a person does. That means it won’t break on canvas-heavy applications, complex single-page apps, or custom components that never implemented proper semantic markup, because it doesn’t read the DOM at all.

Whether that becomes genuinely useful for people who find conventional web interfaces difficult is an open question. I don’t know the answer. But the capability is emerging as a side effect of the core architecture, not as a feature someone has to fund or prioritize, and that seems worth noting. It’s also worth noting that vision-based navigation implies serious GPU requirements — this isn’t a lightweight assistive tool. It’s a capable machine doing expensive inference. Those constraints are real and I won’t pretend otherwise.