Internal request forms

Every team runs on requests. Someone needs access to a tool, a new laptop, a day off, a vendor approved. And almost every team handles those requests with the same three broken options: a shared spreadsheet nobody trusts, a Slack message that scrolls away, or an email thread that loses the reply that mattered.

The status quo is a spreadsheet pretending to be a workflow

The spreadsheet has no owner routing, so requests sit unassigned. Slack has no status, so "did anyone do this?" is a daily question. Email has no record, so at the end of the quarter you cannot say who asked for what or how long it took. None of these were built to be an intake system. They just got drafted into the job because standing up a real one meant auth, a database, and hosting for what is, honestly, a form.

The fuast version is one small app

On fuast an internal request form is a single capsule: a form your coworkers open with a link, a table that logs every submission, and a rule that emails the right owner and tracks status from pending to done. It is an internal tool that took an afternoon instead of a ticket-and-a-quarter.

Steal this prompt

Paste this to your AI. It reads the fuast contract at /llms.txt and writes the whole thing.

Build a fuast capsule for internal requests. A signed-in coworker submits a request with a type (access, hardware, or PTO) and a short description. Store the submitter from the verified identity, never from a form field. Email it-team@ourco.com when a request comes in. Show me a list of all requests with their status, and let an owner move a request from pending to approved or denied. Then deploy it and share it with the workspace.

What makes it real on fuast

The reason this is a real tool and not a form dump is what fuast includes:

• Built-in auth means it sees who submitted. The request is stamped with the verified ctx.auth.userId, not a name typed into a box someone can fake. IT knows exactly who asked.
• A real database logs every request with a createdAt, so status tracking and "how long did this take" reporting are just queries.
• Transactional email routes each new request to the right owner the moment it lands, with no separate mail service to wire up.

A slice of the server half:

import { capsule, table, string, text, mutation, query } from "fuast/server";

export default capsule({
  schema: {
    requests: table({
      kind: string(),        // "access" | "hardware" | "pto"
      detail: text(),
      requestedBy: string(),
      status: string(),      // "pending" | "approved" | "denied"
    }).index("by_status", ["status"]),
  },
  queries: {
    all: query(async (ctx) => ctx.db.requests.order("desc").collect()),
  },
  mutations: {
    submit: mutation(async (ctx, kind: string, detail: string) => {
      if (ctx.auth.isGuest) throw new Error("sign in first");
      const row = await ctx.db.requests.insert({
        kind, detail, requestedBy: ctx.auth.userId, status: "pending",
      });
      await ctx.email.send({
        to: "it-team@ourco.com",
        subject: `New ${kind} request`,
        text: detail,
      });
      return row;
    }),
  },
});

That is a working backend: verified submitter, routed email, tracked status. No server to provision, no auth to bolt on.

Ship it to your team

An intake form your coworkers open from a link, that logs who asked and pings the right owner, is the exact shape fuast was built for. Read more on internal tools without a platform team, then build one for real.