App Studio

Describe a tool. Get a working website.

Trackers, dashboards, request forms and internal portals, built by an agent with a real database, an API and authentication, then published for your team.

  • From a sentence to a site

    One request becomes a full app: pages, data, API and sign-in.

  • A real database

    Postgres with migrations, and production kept apart from what you test.

  • Published in a click

    A live address your team can open and sign in to.

How it works

From a request to a live app in four steps.

  1. 01

    Describe it

    Say what you need in a sentence or a page: who uses it, what they track, what they should see. App Studio’s agent plans the pages, the data model and the API before it writes a line.

    • Plain-language requests, attachments and screenshots
    • Asks when something is unclear instead of guessing
  2. 02

    Watch it build

    The agent writes a real codebase and runs it in an isolated dev server, with a live preview beside the chat. Errors from the preview’s browser are fed straight back to it, so it fixes what breaks.

    • React 19, Vite and Tailwind for the interface
    • An API in TypeScript (Hono), and a Postgres database with versioned migrations
    • Authentication built in: email and password, or Google sign-in brokered by Pulsar, with no keys to set up
    • Anyone in the project can open the preview link
  3. 03

    Check the data

    Every app has two databases: dev, which the preview uses, and production, which the published site uses. The Data tab lets you browse tables and run SQL against either.

    • Production is read-only in the Data tab, and every query against it is logged
    • A Postgres connection URL for your BI tools, with the password reset in one click
    • Reset dev to empty at any time; it never copies production data
  4. 04

    Publish

    One click builds the site, runs the production migrations and deploys the API. The app goes live at its own address, ready for your team to sign in.

    • Live at your-app.pulsarbot.app
    • Unpublish takes the site and its API down together
    • Settings and keys per environment, encrypted, and copied from Pulsar’s secrets without appearing in the chat

Agents and routines

Apps that keep themselves up to date.

A published app is not a dead end. Pulsar’s agents can read its live data from any chat in the project, and an automation, a routine tied to the app, can fill it in on a schedule: checking sources, browsing the web, and writing the results back.

Refresh vendor risk

Routine · every day at 07:30 · App: Vendor tracker

  1. app_data query
    SELECT id, name, website FROM vendors WHERE review_due <= now()
  2. browse northwind-logistics.com/security
  3. app_data query write
    UPDATE vendors SET risk = 'High', reviewed_at = now() WHERE id = 12

3 vendors re-checked, 1 moved to High risk

Ask in any project chat

Procurement project · reads the published app

Which high-risk vendors renew this quarter?

app_data query
SELECT name, renews_on FROM vendors WHERE risk = 'High' AND renews_on < '2026-12-31'

Two: Halcyon Print renews on 14/11 and Northwind Logistics on 02/12. Northwind still has no data-processing agreement.

  • Anyone can ask

    Every project member’s chats can read the app’s live data.

  • Admins can change it

    In chat, only the app’s creator or a project admin can have the agent write.

  • Automations keep it fresh

    Routines the creator ties to the app can write on their schedule; other routines only read.

  • Rows, never structure

    Agents insert, update and delete rows. Schema changes only happen in App Studio, and every query is logged.

Under the hood

A real stack, not a toy.

  • Interface

    React 19, Vite, Tailwind CSS and React Router, in TypeScript.

  • API

    Hono functions in TypeScript. In production they run as serverless functions beside the database.

  • Database

    Postgres, with a Drizzle schema and versioned migrations. Separate dev and production databases.

  • Authentication

    Better Auth with email and password, or Google sign-in through Pulsar. Hardened cookies and same-origin checks.

  • Secrets

    Per-environment settings, encrypted at rest. The agent and the browser only ever see their names.

  • Isolation

    The dev server runs sandboxed, apart from the rest of the workspace. Production builds are packed there too.

App Studio questions

Do I need to know how to code?

No. You describe what you want and review the result in the preview. The code is real and yours to inspect, but you never have to touch it.

Where do published apps live?

At their own address on pulsarbot.app, for example vendor-tracker-ab12.pulsarbot.app. Custom domains are not available yet.

Can an agent change my live data?

Only in two cases: an app admin asks for it in chat, or an automation the app’s creator set up runs. Anyone else’s chats and routines can only read. Agents can insert, update and delete rows, never change the database’s structure, and every query against production is logged.

How do I change the app later?

Open it in App Studio and ask. The agent edits the code and the database schema in dev, you check the preview, and you publish again when you are happy.

How many apps can I build?

One on Free, 5 on Pro, 20 on Max, and as many as you need on Enterprise.

Put Pulsar to work.

Start free on Pulsar Cloud, or book 30 minutes with us to see how it would run in your own environment.