Coroin Apps

Two small libraries

• bugkit-core — a self-routing backend over injected auth and storage. Pure Node, no React, no AWS SDK.
• bugkit-ui — a reporter button/modal and an admin triage page, as React components or as a framework-free browser build for hosts without React.

How it fits your app

• Reports and screenshots live in your own DigitalOcean Spaces — one JSON file per bug, no shared database.
• Screenshots aren’t publicly readable; the admin view mints short-lived presigned URLs to fetch them.
• Members submit, admins triage open → fixed → closed. Caller identity comes from your verified login, never the form.
• Screenshots are resized in the browser to stay under the serverless 1 MB request cap.
• An optional daily cap on the admin notification mails: past it, a report is still stored and only the mail is skipped.

How it fits your app

• Never a hard failure. Every submission gets a decision — accept, quarantine, silent-drop, or expired — and grading only throws on host misconfiguration, never on bad or bot input.
• Bots get no signal. A silent-drop returns a normal-looking success response with no email sent.
• Soft signals stay soft. A fingerprint mismatch or missing proof-of-work nonce is scored, not rejected by default — a stale cached page or a mobile IP change degrades to "flagged for review," never a dropped inquiry.
• Single-use tokens. Give it a store and a replayed token is silently dropped. If the store is down it fails closed, and the browser helper re-arms.
• A real visitor is not lost. A small browser helper keeps the token and proof-of-work solution fresh, and holds a submit until the token is old enough for the guard. With no token it shows a message on the form instead of posting. A form’s own submit handler doesn’t change; a fetch caller handles one rejection.
• A daily send cap. A solved proof-of-work buys one mail, so a per-day cap bounds how many one form sends. Past it the visitor is asked to try again tomorrow; if the cap’s store is down, mail still goes.

How it fits your app

• Two-step sign-in. requestLink(email) mints a short-lived magic link and calls your injected mailer; verifyLink(token) redeems it once. A redemption that starts after another has claimed the link is refused. Your store needs no compare-and-swap, and the price is a narrow window: two redemptions that overlap exactly can both pass.
• Tokens know their purpose. A magic-link token is never accepted as a session, and a session is never accepted as a magic link.
• Tiers are your business logic. passkit only validates a tier name against a whitelist you provide — deciding who is a member or an admin stays entirely in your app.
• Secret rotation with a grace period. Configure a previous secret alongside a freshly rotated one; tokens signed before rotation keep verifying until they expire.
• Pairs with sendkit for the email and shardkit for the pending links, but has no dependencies at all. Use it standalone.

Two small libraries

• qrkit-core — SVG generation and tracked URLs for a build script or the browser, plus backend CRUD and an auth-free dispatcher. Pure TypeScript, no native deps.
• qrkit-ui — a React admin page with Active / Inactive / Archived tabs and a live style preview, for hosts that already load React.
• Test doubles — in-memory Spaces and blob mocks so you can unit-test without touching DigitalOcean.
• SVG styling — configurable module and eye shapes, colors, and an embedded logo with error-correction locking.

How it works

• Generate — give it a destination URL, a UTM source, and optional styling; qrkit builds the tracked URL and renders the SVG.
• Embed — drop the generated SVG in with a plain <img> tag. No proxy or redirector — the QR carries the full destination and UTM params.
• Attribute — UTM params flow into GA4 natively; set up a QR channel group once and track it beside your other channels.
• Manage — with the manager, each code is an SVG in Spaces and a JSON record; re-style one and the SVG regenerates over the same key, so your embeds keep working.

Two small libraries

• roadmapkit-core — the data model, which does no I/O, plus a handler for your function and a store over DigitalOcean Spaces.
• roadmapkit-ui — a board with no framework: lanes, search, one-tap edits, and a delivery report. Phone first, light and dark.

How it fits your app

• Your sign-in decides who can edit. You verify the person and pass a role; a reporter reads the whole board and an edit from one is refused.
• Edits are requests. Each is its own object until your sync applies it, so the file keeps one writer.
• A journal of every change. Each one is recorded with who made it, and the report counts what shipped on time, what slipped, and what was dropped.
• Drafts for review. An agent can put a draft on an item, and a reviewer answers it on the board.

Core features

• Swappable transports — Resend, any SMTP server (Amazon SES, Postmark, self-hosted), plus in-memory and console transports for tests.
• Safe contact forms — the recipient is resolved server-side, never read from the request body.
• Magic-link sign-in — sign-in emails with configurable expiry and escaped URLs.
• Canonical escaping — every user-supplied value is HTML-escaped in your templates.

How it fits your app

• The transport is injected at initialization — sendkit never reads process.env itself.
• A low-level send() for custom templates, plus canned sendContactForm and sendMagicLink helpers.
• Honeypot support for contact forms — a silent no-op when the field is filled.
• Typed errors with codes (invalid_recipient, send_failed, honeypot_tripped).

How it fits your app

• One JSON file per record, at ${prefix}${id}.json — concurrent writers to different ids never collide.
• The client is injected. Your host constructs a lightweight aws4fetch client pre-bound with credentials and hands it in — shardkit never reads process.env, and stays out of the full AWS SDK’s cold-start cost.
• Optional read validation via a zod schema or hand-rolled type guard, to catch malformed or legacy-shaped records on the way out.
• Ships a MemoryShardStore for tests — no network, no bucket.

What it decides for you

• One answer is enough — a single rating is a whole response. An email is asked for only when someone ticks a box that needs a reply.
• An unticked box stores nothing — names and emails are cut on the server to what each person allowed.
• A quote needs its own tick — every other takeaway stays private.
• A form that looks sent is stored — on bad conference Wi-Fi the answers stay on screen until they really go.

The dashboard

Each talk page carries its own code, and every response is filed under it, so one dashboard shows every talk. It sits behind your own sign-in. Responses are never shown on the talk page.

How it works

• Add it — the form builds into your page, and a small function on your account takes the answers.
• Store it — each response is its own private record, so a full room answering at once loses nothing, and removing one person is one delete.
• Read it — the dashboard, or a one-line report: ratings, quotes, leads, and who asked for the recording.

Built to iOS Safari’s rules

• A watchdog per paragraph. The end-of-speech event sometimes never fires; the player moves on anyway.
• A screen wake lock. Speech stops when the screen locks, so the screen stays on while it plays.
• Voices load late. It prefers a local voice for the language and picks again when the list changes.
• Leaving stops it. Otherwise iOS keeps talking over the next page.

What a web page can’t do

• Voice commands, playing with the screen locked, and lock-screen controls are not possible from a web page.