Build internal tools for your Startup with Construct AI

Construct AI launches a feature that lets users build private internal tools inside their workspace by describing the job in natural language, with the agent writing React and TypeScript source, validating the build, and opening the app in the Construct web desktop. The workspace apps have a narrower runtime than general web hosting, requiring declared permissions for file access, network requests, and app-scoped state, and their source and data remain in the workspace for inspection and later changes.

How Construct Builds Internal Tools in Your Workspace - internal-tools - workspace-apps - ai-agent - product Internal tools often begin as a spreadsheet, a checklist, or a prompt someone runs every week. The process works, but the interface does not: people copy values between tabs, remember status in their heads, and repeat the same setup each time. Construct can turn that repeated process into a small private app that lives inside the same workspace as the files and agent doing the work. This is not a one-click path to a public SaaS product. A Construct workspace app is a focused internal interface for one workspace. You describe the job, the agent writes the app, checks that it builds, opens it in the desktop, and keeps the source available for inspection and later changes. Start with the repeated process The best request describes the work rather than prescribing a software architecture. For example: - “Build a research request tracker with an owner, priority, status, and link to the finished report.” - “Turn this recurring launch checklist into an app the team can update.” - “Create a dashboard for the JSON reports stored in this workspace.” - “Build an intake form for customer-review requests and keep the queue in one place.” Construct can start from a list, form, dashboard, or blank interface. The agent creates the app package, writes the React and TypeScript source, declares the capabilities it needs, and validates the result. A successful build opens directly in the Construct web desktop instead of sending you to a separate hosting project. The request still matters. “Build an operations dashboard” leaves important choices unresolved. “Show open research requests, let an operator assign an owner, and mark the linked report as reviewed” gives the agent a bounded workflow and a clear way to tell whether the app is useful. The app lives beside the work A workspace app is not a hidden artifact. Its source lives under an Apps/<app-id / folder in Files, where it can be inspected and edited. After a successful build, the app appears as a private workspace install that can be reopened from the desktop, Launchpad, or Spotlight. The app's durable state is kept separately under AppData/<app-id / . That separation is important: changing the interface should not require overwriting the records the app already manages. Rebuilding can update the code while existing app data remains in the workspace and continues to count against the normal workspace storage quota. This model also makes the surrounding agent useful after launch. The same workspace contains the source, relevant files, conversations, and diagnostics. If the interface needs another field or a runtime error appears, the next task can start with the actual app rather than a screenshot and a vague bug report. What a workspace app can do The current runtime is intentionally narrower than a general web-hosting platform. That keeps an internal tool close to its workspace purpose. | Capability | Current workspace-app support | |---|---| | React interface | Yes | | TypeScript and TSX | Yes | | Read or write workspace files | With declared permission | | App-scoped JSON state | With declared Files permission | | Call an allowed connected app | With an explicit app allowlist | | Make direct network requests | Only to declared HTTPS origins | | Install arbitrary npm packages | No | | Run terminal or agent orchestration from the app UI | No | | Publish automatically to the public app registry | No | The app UI receives a small Construct SDK for workspace files, app-scoped storage, notifications, window controls, and explicitly permitted calls. It does not inherit every tool available to the agent that authored it. The agent can use broader execution surfaces while building, but the finished interface runs with its own narrower contract. Permissions are part of the design An internal tool should not gain broad access simply because it was generated inside a trusted workspace. A workspace app declares the native capabilities, connected apps, and network origins it intends to use. Calls outside those allowlists are denied at runtime. The platform also rechecks current workspace membership and permissions when the app makes a gateway call. File operations remain subject to the user's workspace access, and an app cannot use its file access to rewrite another app's package. Direct network access is limited to exact HTTPS origins rather than wildcard domains. For a request tracker that only reads and writes workspace files, that can mean declaring Files access and nothing else. A tool that posts an approved record to a connected service needs that specific app target as well. The useful default is the smallest permission set that completes the job. Validation creates a build, not a guarantee Before launch, Construct checks the package structure and manifest, follows relative imports, enforces package boundaries, compiles the TypeScript and JSX, and reports design findings. A successful validation creates an immutable artifact with a deterministic build ID and opens the app. That proves the package can be built under the workspace runtime. It does not prove that every button, data shape, connected service, or edge case behaves correctly. Runtime verification still matters, especially after changing permissions, storage behavior, or an external call. Construct captures bounded console, network, gateway, and runtime-error diagnostics from workspace apps. The agent can inspect recent errors, repair the source, validate again, and ask you to verify the changed behavior. The loop is closer to maintaining a small internal product than generating a disposable code snippet. Draft changes do not replace the last good build The reliability model is deliberately conservative. A successful build becomes the current runtime artifact. Later source edits mark the app as having draft changes, but opening the app continues to run the last successful build until the new source validates. If validation fails, the working artifact is not replaced. Cancelling an edit also leaves both the source and prior build in place. The desktop can show whether an app is ready, has draft changes, or has never built successfully. This is a last-good-build fallback, not full version history. It protects the working tool while a repair is in progress; it does not promise browsing or restoring every historical build. Internal tool or workflow? Not every repeated process needs an interface. Use a workspace app when people need to view, enter, filter, or review state. Use a Construct workflow when the main value is running a known sequence of agent steps, connected-app actions, and notifications. Use a scheduled agent job when the process should run in the background without waiting for someone to open a screen. The two can support the same operation. A workspace app can provide the queue and review surface, while files hold durable records and a scheduled job prepares new work. The important boundary is that the app UI does not secretly become an unrestricted agent: automation still runs through the execution surfaces and permissions designed for it. Where workspace apps fit Good fits are narrow tools with a clear operator and a durable workspace context: - Intake forms and review queues - Checklists for repeated operations - Lightweight trackers over workspace records - Dashboards for files or app-scoped JSON data - Focused interfaces over an explicitly allowed connected service - Small utilities that make an existing workflow easier to run and inspect Poor fits include public customer-facing sites, products that require an arbitrary npm ecosystem, complex multi-service systems, or workloads that need independently operated infrastructure and security controls. Public registry apps also follow a separate developer and review workflow; a private workspace build is not automatically promoted to the public app registry. Build the smallest useful interface The shortest path is to start with one repeated process and one person who needs to operate it. Name the records the app should manage, the actions the operator should take, the files or services it may access, and what a successful result looks like. Then ask Construct to build the smallest interface that makes that process easier to run and supervise. Once the first build opens, use it. The missing field, unclear status, or unnecessary screen becomes obvious faster in a working tool than in a long specification. Construct can revise the source while the previous good build remains available, giving the internal tool room to improve without turning every edit into a fresh software project.