Productivity · Weekend build
Build your own TextExpander
Whole sentences from three keystrokes, witnessed by no one. TextExpander charges $4.16–$8.33 per month — that’s $50–$100 a year — for something you can replace with focused software of your own. Here is the honest scope, the honest timeline, and the exact prompt to hand your coding agent.
Who this replacement is for
This build targets one Mac user who types the same things every day. The goal: expand abbreviations into snippets anywhere on the system while every keystroke stays on the machine. If you need more than that, keep paying — the point of building it yourself is owning a tool shaped exactly like your workflow, not re-implementing a venture-funded roadmap.
Same build, different logo: this v1 also replaces aText and Espanso — they all solve the same core job.
How long it actually takes
One number would be a lie, so here are three. Each tier is a real, usable product — pick the one that matches how much of TextExpander you actually use.
| Estimate | What you get |
|---|---|
| 10 hours | expansion, placeholders, date math, per-app disable |
| 3 days | folders, quick-search palette, usage stats, backups |
| 3 months+ | team sharing, cloud sync, windows and ios apps — the part you should probably skip |
What a minimal TextExpander alternative needs
- abbreviation triggers that expand system-wide via the accessibility APIs
- fill-in placeholders completed in a small popup before insertion
- date math like {date+3d} for deadlines and follow-ups
- per-app disable for password managers and terminals
- a searchable local snippet library stored as a plain file
Data model
Snippet, Abbreviation, Placeholder, AppRule
Integrations
macOS Accessibility API, local file storage
Capability context
SwiftUI, Swift, macOS
The guardrail
Process every keystroke locally and in memory only, never log or transmit typed text, and store nothing outside the local snippet library.
Deliberate non-goals
Do not build cloud sync, team snippet sharing, a Windows or iOS port, or usage analytics of any kind.
The complete build prompt
Copy this into your coding agent of choice. It is scoped for a useful v1 — journeys, screens, business rules, data model, security, tests, and acceptance scenarios included. Pick your stack:
You are building a production-ready software product named “Snipkey”, a deliberately focused alternative to TextExpander. Build a complete, usable vertical slice—not a landing page, static mockup, or disconnected collection of components.
WORKING AGREEMENT
Before writing implementation code, produce a short technical plan that names the routes or pages, server actions or endpoints, data tables, important state transitions, authorization boundaries, background jobs, and external adapters. Resolve contradictions in favor of the narrow audience and non-goals below. Prefer a small, legible architecture over speculative abstraction, but do not omit persistence, validation, error handling, or tests.
PRODUCT BRIEF
Primary user: one Mac user who types the same things every day.
Primary outcome: expand abbreviations into snippets anywhere on the system while every keystroke stays on the machine.
Product principle: optimize the exact workflow below instead of copying the full breadth of TextExpander. A first-time user should understand what to do from the interface itself, without a tour or documentation.
END-TO-END USER JOURNEYS
Implement all of these flows through the real interface and persistent data layer:
1. The user creates a ;sig abbreviation, types it in a mail client, and watches the full signature appear in place with the cursor left at the end.
2. The user triggers a meeting snippet with fill-in placeholders, completes the name and {date+3d} fields in the popup, and inserts the finished text.
3. The user disables expansion inside a password manager and a terminal, confirms triggers do nothing there, and verifies the snippet library lives only on the local disk.
SCREENS AND INFORMATION ARCHITECTURE
Build these as coherent responsive views. Each screen must specify its primary action, secondary actions, visible status, validation feedback, empty state, loading or pending state, success confirmation, and recoverable failure state.
1. Library: snippet list with abbreviations, content previews, search, and a new-snippet action alongside the local file location.
2. Snippet editor: abbreviation field with conflict warnings, a content editor with placeholder and date-math insertion menus, and a test-expansion area.
3. App rules: running and recent applications with per-app enable toggles and a default-deny list for sensitive app categories.
4. Status and permissions: menu-bar state, an Accessibility permission walkthrough, a pause-all toggle, and a plain statement of what is never collected.
CORE CAPABILITIES
1. abbreviation triggers that expand system-wide via the accessibility APIs
2. fill-in placeholders completed in a small popup before insertion
3. date math like {date+3d} for deadlines and follow-ups
4. per-app disable for password managers and terminals
5. a searchable local snippet library stored as a plain file
DETAILED BEHAVIOR AND BUSINESS RULES
Treat these as server-enforced product requirements, not interface suggestions:
1. Observe keystrokes only through the Accessibility APIs in local memory, keep a rolling buffer no longer than the longest abbreviation, and never write typed text to disk or logs.
2. Expand only on an exact abbreviation match followed by a configured delimiter, and replace the typed trigger atomically so no partial state is left in the target field.
3. Check per-app disable rules and secure-input state before processing any keystroke, and ship with password managers and secure fields excluded by default.
4. Store the snippet library in a plain local file with no network access, no telemetry, and no cloud sync of any kind.
DATA MODEL AND LIFECYCLE
Design a small relational schema centered on Snippet, Abbreviation, Placeholder, AppRule. Before implementing it, document:
1. Each table’s purpose, primary key, ownership or tenant boundary, timestamps, status fields, and important attributes.
2. Foreign keys, uniqueness constraints, check constraints, indexes needed by the named screens, and transaction boundaries for multi-record changes.
3. The allowed lifecycle or state transitions, who may trigger each transition, which transitions are terminal or reversible, and what audit history must remain immutable.
4. Archive, retention, and deletion behavior, including what happens to dependent records and external files.
5. Idempotency strategy for submissions, jobs, imports, notifications, webhooks, or retries where applicable.
Use migrations rather than ad-hoc schema creation. Store time instants consistently and retain named timezone context whenever local schedules or dates matter. Never rely on a counter, disabled button, or client-side check to preserve a business invariant.
USERS, AUTHENTICATION, AND PERMISSIONS
Implement only the roles required by the stated audience. Make the ownership and visibility model explicit before coding. Enforce authorization in every server-side query and mutation, including search, exports, attachments, live updates, and guessed URLs—not merely by hiding controls. Use secure session defaults, protect state-changing requests, and provide an understandable signed-out, expired-session, and forbidden state. Seed distinct users when multiple roles are required so permissions can be demonstrated and tested.
INTERACTION AND VISUAL DIRECTION
The product should feel fast, calm, focused, and credible rather than like a generic admin template. Use a clear visual hierarchy, restrained color, readable typography, generous hit targets, and consistent placement for primary actions. Start with server-rendered HTML and progressively enhance only the interactions that benefit from it. The core workflow must remain understandable if enhancement fails.
Start with server-rendered Astro pages and ordinary HTML forms. Use HTMX for form submissions, partial navigation, and server-driven updates, then Alpine.js only for small local browser state. The core workflow must remain understandable if either enhancement layer fails.
Design mobile layouts intentionally instead of simply stacking desktop panels. Support keyboard navigation, visible focus, semantic landmarks, explicit labels, useful page titles, reduced-motion preferences, and screen-reader announcements for asynchronous results. Never use color alone to communicate state. Destructive actions require clear scope and confirmation; safe repeated actions should be idempotent.
TECHNICAL DIRECTION
Build this version with the AHA stack: Astro for routing, layouts, and server-rendered pages; HTMX for interactions that benefit from HTML fragment responses; and Alpine.js for small, local interface state. Prefer Cloudflare D1 for relational persistence, R2 for object storage, Workers for server endpoints and scheduled work, Durable Objects only for coordinated real-time state, and Workflows or Queues for durable background jobs—but only when the product requirements call for them.
Keep domain rules in testable server-side modules instead of route handlers or UI components. Separate persistence, external providers, and background work behind small interfaces without building a framework. Prefer ordinary HTML forms and URLs for durable navigation; use optimistic interaction only when failure can be reconciled clearly.
The product brief currently identifies SwiftUI, Swift, macOS as capability context. Preserve any required native, browser-only, edge, storage, real-time, or background-processing capability through a narrow adapter appropriate to the selected framework. If the core workflow genuinely requires native or browser APIs, keep that runtime as the primary execution surface rather than simulating inaccessible capabilities or inventing an unnecessary web surface.
Integrate with macOS Accessibility API and local file storage. For every integration:
- List required environment variables in an .env.example without real secrets.
- Add a small adapter with timeouts, normalized errors, and a deterministic local fake or development path.
- Verify inbound signatures and deduplicate provider events where supported.
- Keep credentials server-side, encrypt long-lived provider tokens at rest, and redact secrets and sensitive payloads from logs.
- Define retry, backoff, and idempotency behavior for any side effect that can be repeated.
SECURITY AND PRIVACY
Process every keystroke locally and in memory only, never log or transmit typed text, and store nothing outside the local snippet library.
Validate, normalize, and length-limit all untrusted input on the server. Escape rendered content by default, sanitize any intentionally accepted markup, rate-limit public or abuse-prone actions, and use private object storage plus short-lived authorized URLs for sensitive files. Collect the minimum personal data necessary for the named workflow. Document retention and deletion behavior. Add specific protections for the riskier surfaces in this app, such as uploads, redirects, outbound requests, email delivery, OAuth, webhooks, CSV import or export, and real-time connections.
ACCEPTANCE SCENARIOS
Automate these app-specific scenarios at the most appropriate level:
1. Given the user types an abbreviation inside a disabled app, nothing expands and nothing about the keystrokes is retained.
2. Given a fill-in snippet is triggered, canceling the popup inserts nothing and leaves the typed abbreviation for the user to keep or delete.
3. Given {date+3d} appears in a snippet expanded on a Friday, the result contains the correct following Monday in the user’s locale format.
TESTING
Add focused unit tests for state transitions, authorization predicates, normalization, date or money calculations, and other risky domain rules. Add integration tests for persistence constraints and each external adapter’s success, timeout, retry, and rejection paths. Add at least one browser-level test for every end-to-end journey above, including one small-screen viewport. Tests must use isolated data and run through a documented single command.
OPERATIONS AND FAILURE RECOVERY
Add structured server logs with request, job, or event correlation IDs but no secrets or unnecessarily sensitive data. Make failures actionable in both the interface and logs. Background work must expose pending, succeeded, failed, and retrying states where relevant; do not silently swallow errors. Include safe database migration and rollback guidance, seed data, backup and restore notes, external-data cleanup behavior, and a basic health or diagnostic path appropriate to the stack.
DELIVERABLES
Ship the working application, migrations, representative seed data, tests, .env.example, and a concise README. The README must cover prerequisites, local setup, environment variables, migrations, seed and test commands, deployment, integration setup, backup and restore, security decisions, and known limitations. Seed data should exercise the happy path plus at least one empty, failed, overdue, expired, archived, or permission-restricted state relevant to the product.
DEFINITION OF DONE
The app is complete when a fresh developer can follow the README, create and migrate the database, run the app, sign in as each relevant role, complete every named journey using real persisted data, refresh without losing state, recover from common failures, and use the core interface on phone and desktop. All acceptance scenarios pass, permission boundaries are covered by tests, and no core screen is left as a placeholder.
NON-GOALS
Do not build cloud sync, team snippet sharing, a Windows or iOS port, or usage analytics of any kind.You are building a production-ready software product named “Snipkey”, a deliberately focused alternative to TextExpander. Build a complete, usable vertical slice—not a landing page, static mockup, or disconnected collection of components.
WORKING AGREEMENT
Before writing implementation code, produce a short technical plan that names the routes or pages, server actions or endpoints, data tables, important state transitions, authorization boundaries, background jobs, and external adapters. Resolve contradictions in favor of the narrow audience and non-goals below. Prefer a small, legible architecture over speculative abstraction, but do not omit persistence, validation, error handling, or tests.
PRODUCT BRIEF
Primary user: one Mac user who types the same things every day.
Primary outcome: expand abbreviations into snippets anywhere on the system while every keystroke stays on the machine.
Product principle: optimize the exact workflow below instead of copying the full breadth of TextExpander. A first-time user should understand what to do from the interface itself, without a tour or documentation.
END-TO-END USER JOURNEYS
Implement all of these flows through the real interface and persistent data layer:
1. The user creates a ;sig abbreviation, types it in a mail client, and watches the full signature appear in place with the cursor left at the end.
2. The user triggers a meeting snippet with fill-in placeholders, completes the name and {date+3d} fields in the popup, and inserts the finished text.
3. The user disables expansion inside a password manager and a terminal, confirms triggers do nothing there, and verifies the snippet library lives only on the local disk.
SCREENS AND INFORMATION ARCHITECTURE
Build these as coherent responsive views. Each screen must specify its primary action, secondary actions, visible status, validation feedback, empty state, loading or pending state, success confirmation, and recoverable failure state.
1. Library: snippet list with abbreviations, content previews, search, and a new-snippet action alongside the local file location.
2. Snippet editor: abbreviation field with conflict warnings, a content editor with placeholder and date-math insertion menus, and a test-expansion area.
3. App rules: running and recent applications with per-app enable toggles and a default-deny list for sensitive app categories.
4. Status and permissions: menu-bar state, an Accessibility permission walkthrough, a pause-all toggle, and a plain statement of what is never collected.
CORE CAPABILITIES
1. abbreviation triggers that expand system-wide via the accessibility APIs
2. fill-in placeholders completed in a small popup before insertion
3. date math like {date+3d} for deadlines and follow-ups
4. per-app disable for password managers and terminals
5. a searchable local snippet library stored as a plain file
DETAILED BEHAVIOR AND BUSINESS RULES
Treat these as server-enforced product requirements, not interface suggestions:
1. Observe keystrokes only through the Accessibility APIs in local memory, keep a rolling buffer no longer than the longest abbreviation, and never write typed text to disk or logs.
2. Expand only on an exact abbreviation match followed by a configured delimiter, and replace the typed trigger atomically so no partial state is left in the target field.
3. Check per-app disable rules and secure-input state before processing any keystroke, and ship with password managers and secure fields excluded by default.
4. Store the snippet library in a plain local file with no network access, no telemetry, and no cloud sync of any kind.
DATA MODEL AND LIFECYCLE
Design a small relational schema centered on Snippet, Abbreviation, Placeholder, AppRule. Before implementing it, document:
1. Each table’s purpose, primary key, ownership or tenant boundary, timestamps, status fields, and important attributes.
2. Foreign keys, uniqueness constraints, check constraints, indexes needed by the named screens, and transaction boundaries for multi-record changes.
3. The allowed lifecycle or state transitions, who may trigger each transition, which transitions are terminal or reversible, and what audit history must remain immutable.
4. Archive, retention, and deletion behavior, including what happens to dependent records and external files.
5. Idempotency strategy for submissions, jobs, imports, notifications, webhooks, or retries where applicable.
Use migrations rather than ad-hoc schema creation. Store time instants consistently and retain named timezone context whenever local schedules or dates matter. Never rely on a counter, disabled button, or client-side check to preserve a business invariant.
USERS, AUTHENTICATION, AND PERMISSIONS
Implement only the roles required by the stated audience. Make the ownership and visibility model explicit before coding. Enforce authorization in every server-side query and mutation, including search, exports, attachments, live updates, and guessed URLs—not merely by hiding controls. Use secure session defaults, protect state-changing requests, and provide an understandable signed-out, expired-session, and forbidden state. Seed distinct users when multiple roles are required so permissions can be demonstrated and tested.
INTERACTION AND VISUAL DIRECTION
The product should feel fast, calm, focused, and credible rather than like a generic admin template. Use a clear visual hierarchy, restrained color, readable typography, generous hit targets, and consistent placement for primary actions. Start with server-rendered HTML and progressively enhance only the interactions that benefit from it. The core workflow must remain understandable if enhancement fails.
Render with React Server Components by default. Use Server Actions for authenticated form mutations and add Client Components only for interactions that genuinely require browser state, browser APIs, drag-and-drop, or live updates. The core workflow must remain understandable before client-side JavaScript finishes loading.
Design mobile layouts intentionally instead of simply stacking desktop panels. Support keyboard navigation, visible focus, semantic landmarks, explicit labels, useful page titles, reduced-motion preferences, and screen-reader announcements for asynchronous results. Never use color alone to communicate state. Destructive actions require clear scope and confirmation; safe repeated actions should be idempotent.
TECHNICAL DIRECTION
Build this version with Next.js, the App Router, and TypeScript. Use Server Components by default, Server Actions for authenticated mutations, and Route Handlers for public APIs, OAuth callbacks, webhooks, feeds, uploads, and downloads. Use PostgreSQL through Drizzle ORM with versioned migrations and an isolated test database. Access S3-compatible object storage through a server-only adapter, and run slow or retryable work in a real job or workflow system instead of the request lifecycle.
Keep domain rules in testable server-side modules instead of route handlers or UI components. Separate persistence, external providers, and background work behind small interfaces without building a framework. Prefer ordinary HTML forms and URLs for durable navigation; use optimistic interaction only when failure can be reconciled clearly.
The product brief currently identifies SwiftUI, Swift, macOS as capability context. Preserve any required native, browser-only, edge, storage, real-time, or background-processing capability through a narrow adapter appropriate to the selected framework. If the core workflow genuinely requires native or browser APIs, keep that runtime as the primary execution surface rather than simulating inaccessible capabilities or inventing an unnecessary web surface.
Integrate with macOS Accessibility API and local file storage. For every integration:
- List required environment variables in an .env.example without real secrets.
- Add a small adapter with timeouts, normalized errors, and a deterministic local fake or development path.
- Verify inbound signatures and deduplicate provider events where supported.
- Keep credentials server-side, encrypt long-lived provider tokens at rest, and redact secrets and sensitive payloads from logs.
- Define retry, backoff, and idempotency behavior for any side effect that can be repeated.
SECURITY AND PRIVACY
Process every keystroke locally and in memory only, never log or transmit typed text, and store nothing outside the local snippet library.
Validate, normalize, and length-limit all untrusted input on the server. Escape rendered content by default, sanitize any intentionally accepted markup, rate-limit public or abuse-prone actions, and use private object storage plus short-lived authorized URLs for sensitive files. Collect the minimum personal data necessary for the named workflow. Document retention and deletion behavior. Add specific protections for the riskier surfaces in this app, such as uploads, redirects, outbound requests, email delivery, OAuth, webhooks, CSV import or export, and real-time connections.
ACCEPTANCE SCENARIOS
Automate these app-specific scenarios at the most appropriate level:
1. Given the user types an abbreviation inside a disabled app, nothing expands and nothing about the keystrokes is retained.
2. Given a fill-in snippet is triggered, canceling the popup inserts nothing and leaves the typed abbreviation for the user to keep or delete.
3. Given {date+3d} appears in a snippet expanded on a Friday, the result contains the correct following Monday in the user’s locale format.
TESTING
Add focused unit tests for state transitions, authorization predicates, normalization, date or money calculations, and other risky domain rules. Add integration tests for persistence constraints and each external adapter’s success, timeout, retry, and rejection paths. Add at least one browser-level test for every end-to-end journey above, including one small-screen viewport. Tests must use isolated data and run through a documented single command.
OPERATIONS AND FAILURE RECOVERY
Add structured server logs with request, job, or event correlation IDs but no secrets or unnecessarily sensitive data. Make failures actionable in both the interface and logs. Background work must expose pending, succeeded, failed, and retrying states where relevant; do not silently swallow errors. Include safe database migration and rollback guidance, seed data, backup and restore notes, external-data cleanup behavior, and a basic health or diagnostic path appropriate to the stack.
DELIVERABLES
Ship the working application, migrations, representative seed data, tests, .env.example, and a concise README. The README must cover prerequisites, local setup, environment variables, migrations, seed and test commands, deployment, integration setup, backup and restore, security decisions, and known limitations. Seed data should exercise the happy path plus at least one empty, failed, overdue, expired, archived, or permission-restricted state relevant to the product.
DEFINITION OF DONE
The app is complete when a fresh developer can follow the README, create and migrate the database, run the app, sign in as each relevant role, complete every named journey using real persisted data, refresh without losing state, recover from common failures, and use the core interface on phone and desktop. All acceptance scenarios pass, permission boundaries are covered by tests, and no core screen is left as a placeholder.
NON-GOALS
Do not build cloud sync, team snippet sharing, a Windows or iOS port, or usage analytics of any kind.You are building a production-ready software product named “Snipkey”, a deliberately focused alternative to TextExpander. Build a complete, usable vertical slice—not a landing page, static mockup, or disconnected collection of components.
WORKING AGREEMENT
Before writing implementation code, produce a short technical plan that names the routes or pages, server actions or endpoints, data tables, important state transitions, authorization boundaries, background jobs, and external adapters. Resolve contradictions in favor of the narrow audience and non-goals below. Prefer a small, legible architecture over speculative abstraction, but do not omit persistence, validation, error handling, or tests.
PRODUCT BRIEF
Primary user: one Mac user who types the same things every day.
Primary outcome: expand abbreviations into snippets anywhere on the system while every keystroke stays on the machine.
Product principle: optimize the exact workflow below instead of copying the full breadth of TextExpander. A first-time user should understand what to do from the interface itself, without a tour or documentation.
END-TO-END USER JOURNEYS
Implement all of these flows through the real interface and persistent data layer:
1. The user creates a ;sig abbreviation, types it in a mail client, and watches the full signature appear in place with the cursor left at the end.
2. The user triggers a meeting snippet with fill-in placeholders, completes the name and {date+3d} fields in the popup, and inserts the finished text.
3. The user disables expansion inside a password manager and a terminal, confirms triggers do nothing there, and verifies the snippet library lives only on the local disk.
SCREENS AND INFORMATION ARCHITECTURE
Build these as coherent responsive views. Each screen must specify its primary action, secondary actions, visible status, validation feedback, empty state, loading or pending state, success confirmation, and recoverable failure state.
1. Library: snippet list with abbreviations, content previews, search, and a new-snippet action alongside the local file location.
2. Snippet editor: abbreviation field with conflict warnings, a content editor with placeholder and date-math insertion menus, and a test-expansion area.
3. App rules: running and recent applications with per-app enable toggles and a default-deny list for sensitive app categories.
4. Status and permissions: menu-bar state, an Accessibility permission walkthrough, a pause-all toggle, and a plain statement of what is never collected.
CORE CAPABILITIES
1. abbreviation triggers that expand system-wide via the accessibility APIs
2. fill-in placeholders completed in a small popup before insertion
3. date math like {date+3d} for deadlines and follow-ups
4. per-app disable for password managers and terminals
5. a searchable local snippet library stored as a plain file
DETAILED BEHAVIOR AND BUSINESS RULES
Treat these as server-enforced product requirements, not interface suggestions:
1. Observe keystrokes only through the Accessibility APIs in local memory, keep a rolling buffer no longer than the longest abbreviation, and never write typed text to disk or logs.
2. Expand only on an exact abbreviation match followed by a configured delimiter, and replace the typed trigger atomically so no partial state is left in the target field.
3. Check per-app disable rules and secure-input state before processing any keystroke, and ship with password managers and secure fields excluded by default.
4. Store the snippet library in a plain local file with no network access, no telemetry, and no cloud sync of any kind.
DATA MODEL AND LIFECYCLE
Design a small relational schema centered on Snippet, Abbreviation, Placeholder, AppRule. Before implementing it, document:
1. Each table’s purpose, primary key, ownership or tenant boundary, timestamps, status fields, and important attributes.
2. Foreign keys, uniqueness constraints, check constraints, indexes needed by the named screens, and transaction boundaries for multi-record changes.
3. The allowed lifecycle or state transitions, who may trigger each transition, which transitions are terminal or reversible, and what audit history must remain immutable.
4. Archive, retention, and deletion behavior, including what happens to dependent records and external files.
5. Idempotency strategy for submissions, jobs, imports, notifications, webhooks, or retries where applicable.
Use migrations rather than ad-hoc schema creation. Store time instants consistently and retain named timezone context whenever local schedules or dates matter. Never rely on a counter, disabled button, or client-side check to preserve a business invariant.
USERS, AUTHENTICATION, AND PERMISSIONS
Implement only the roles required by the stated audience. Make the ownership and visibility model explicit before coding. Enforce authorization in every server-side query and mutation, including search, exports, attachments, live updates, and guessed URLs—not merely by hiding controls. Use secure session defaults, protect state-changing requests, and provide an understandable signed-out, expired-session, and forbidden state. Seed distinct users when multiple roles are required so permissions can be demonstrated and tested.
INTERACTION AND VISUAL DIRECTION
The product should feel fast, calm, focused, and credible rather than like a generic admin template. Use a clear visual hierarchy, restrained color, readable typography, generous hit targets, and consistent placement for primary actions. Start with server-rendered HTML and progressively enhance only the interactions that benefit from it. The core workflow must remain understandable if enhancement fails.
Start with server-rendered Blade views and ordinary forms. Use Livewire for focused server-driven interactions and Alpine.js only for small local interface state. The core workflow must remain understandable without relying on a client-side application shell.
Design mobile layouts intentionally instead of simply stacking desktop panels. Support keyboard navigation, visible focus, semantic landmarks, explicit labels, useful page titles, reduced-motion preferences, and screen-reader announcements for asynchronous results. Never use color alone to communicate state. Destructive actions require clear scope and confirmation; safe repeated actions should be idempotent.
TECHNICAL DIRECTION
Build this version with Laravel, PHP, Blade, Livewire, and Alpine.js. Use controllers and Blade forms for durable navigation, Livewire for focused interactions, Form Requests for validation, Policies and Gates for authorization, and small application actions or services for domain transitions. Use Eloquent with migrations, database constraints, and transactions; Laravel Storage for private S3-compatible files; queued Jobs for retryable work; the Scheduler for recurring work; and Notifications or Mail for email.
Keep domain rules in testable server-side modules instead of route handlers or UI components. Separate persistence, external providers, and background work behind small interfaces without building a framework. Prefer ordinary HTML forms and URLs for durable navigation; use optimistic interaction only when failure can be reconciled clearly.
The product brief currently identifies SwiftUI, Swift, macOS as capability context. Preserve any required native, browser-only, edge, storage, real-time, or background-processing capability through a narrow adapter appropriate to the selected framework. If the core workflow genuinely requires native or browser APIs, keep that runtime as the primary execution surface rather than simulating inaccessible capabilities or inventing an unnecessary web surface.
Integrate with macOS Accessibility API and local file storage. For every integration:
- List required environment variables in an .env.example without real secrets.
- Add a small adapter with timeouts, normalized errors, and a deterministic local fake or development path.
- Verify inbound signatures and deduplicate provider events where supported.
- Keep credentials server-side, encrypt long-lived provider tokens at rest, and redact secrets and sensitive payloads from logs.
- Define retry, backoff, and idempotency behavior for any side effect that can be repeated.
SECURITY AND PRIVACY
Process every keystroke locally and in memory only, never log or transmit typed text, and store nothing outside the local snippet library.
Validate, normalize, and length-limit all untrusted input on the server. Escape rendered content by default, sanitize any intentionally accepted markup, rate-limit public or abuse-prone actions, and use private object storage plus short-lived authorized URLs for sensitive files. Collect the minimum personal data necessary for the named workflow. Document retention and deletion behavior. Add specific protections for the riskier surfaces in this app, such as uploads, redirects, outbound requests, email delivery, OAuth, webhooks, CSV import or export, and real-time connections.
ACCEPTANCE SCENARIOS
Automate these app-specific scenarios at the most appropriate level:
1. Given the user types an abbreviation inside a disabled app, nothing expands and nothing about the keystrokes is retained.
2. Given a fill-in snippet is triggered, canceling the popup inserts nothing and leaves the typed abbreviation for the user to keep or delete.
3. Given {date+3d} appears in a snippet expanded on a Friday, the result contains the correct following Monday in the user’s locale format.
TESTING
Add focused unit tests for state transitions, authorization predicates, normalization, date or money calculations, and other risky domain rules. Add integration tests for persistence constraints and each external adapter’s success, timeout, retry, and rejection paths. Add at least one browser-level test for every end-to-end journey above, including one small-screen viewport. Tests must use isolated data and run through a documented single command.
OPERATIONS AND FAILURE RECOVERY
Add structured server logs with request, job, or event correlation IDs but no secrets or unnecessarily sensitive data. Make failures actionable in both the interface and logs. Background work must expose pending, succeeded, failed, and retrying states where relevant; do not silently swallow errors. Include safe database migration and rollback guidance, seed data, backup and restore notes, external-data cleanup behavior, and a basic health or diagnostic path appropriate to the stack.
DELIVERABLES
Ship the working application, migrations, representative seed data, tests, .env.example, and a concise README. The README must cover prerequisites, local setup, environment variables, migrations, seed and test commands, deployment, integration setup, backup and restore, security decisions, and known limitations. Seed data should exercise the happy path plus at least one empty, failed, overdue, expired, archived, or permission-restricted state relevant to the product.
DEFINITION OF DONE
The app is complete when a fresh developer can follow the README, create and migrate the database, run the app, sign in as each relevant role, complete every named journey using real persisted data, refresh without losing state, recover from common failures, and use the core interface on phone and desktop. All acceptance scenarios pass, permission boundaries are covered by tests, and no core screen is left as a placeholder.
NON-GOALS
Do not build cloud sync, team snippet sharing, a Windows or iOS port, or usage analytics of any kind.You are building a production-ready software product named “Snipkey”, a deliberately focused alternative to TextExpander. Build a complete, usable vertical slice—not a landing page, static mockup, or disconnected collection of components.
WORKING AGREEMENT
Before writing implementation code, produce a short technical plan that names the routes or pages, server actions or endpoints, data tables, important state transitions, authorization boundaries, background jobs, and external adapters. Resolve contradictions in favor of the narrow audience and non-goals below. Prefer a small, legible architecture over speculative abstraction, but do not omit persistence, validation, error handling, or tests.
PRODUCT BRIEF
Primary user: one Mac user who types the same things every day.
Primary outcome: expand abbreviations into snippets anywhere on the system while every keystroke stays on the machine.
Product principle: optimize the exact workflow below instead of copying the full breadth of TextExpander. A first-time user should understand what to do from the interface itself, without a tour or documentation.
END-TO-END USER JOURNEYS
Implement all of these flows through the real interface and persistent data layer:
1. The user creates a ;sig abbreviation, types it in a mail client, and watches the full signature appear in place with the cursor left at the end.
2. The user triggers a meeting snippet with fill-in placeholders, completes the name and {date+3d} fields in the popup, and inserts the finished text.
3. The user disables expansion inside a password manager and a terminal, confirms triggers do nothing there, and verifies the snippet library lives only on the local disk.
SCREENS AND INFORMATION ARCHITECTURE
Build these as coherent responsive views. Each screen must specify its primary action, secondary actions, visible status, validation feedback, empty state, loading or pending state, success confirmation, and recoverable failure state.
1. Library: snippet list with abbreviations, content previews, search, and a new-snippet action alongside the local file location.
2. Snippet editor: abbreviation field with conflict warnings, a content editor with placeholder and date-math insertion menus, and a test-expansion area.
3. App rules: running and recent applications with per-app enable toggles and a default-deny list for sensitive app categories.
4. Status and permissions: menu-bar state, an Accessibility permission walkthrough, a pause-all toggle, and a plain statement of what is never collected.
CORE CAPABILITIES
1. abbreviation triggers that expand system-wide via the accessibility APIs
2. fill-in placeholders completed in a small popup before insertion
3. date math like {date+3d} for deadlines and follow-ups
4. per-app disable for password managers and terminals
5. a searchable local snippet library stored as a plain file
DETAILED BEHAVIOR AND BUSINESS RULES
Treat these as server-enforced product requirements, not interface suggestions:
1. Observe keystrokes only through the Accessibility APIs in local memory, keep a rolling buffer no longer than the longest abbreviation, and never write typed text to disk or logs.
2. Expand only on an exact abbreviation match followed by a configured delimiter, and replace the typed trigger atomically so no partial state is left in the target field.
3. Check per-app disable rules and secure-input state before processing any keystroke, and ship with password managers and secure fields excluded by default.
4. Store the snippet library in a plain local file with no network access, no telemetry, and no cloud sync of any kind.
DATA MODEL AND LIFECYCLE
Design a small relational schema centered on Snippet, Abbreviation, Placeholder, AppRule. Before implementing it, document:
1. Each table’s purpose, primary key, ownership or tenant boundary, timestamps, status fields, and important attributes.
2. Foreign keys, uniqueness constraints, check constraints, indexes needed by the named screens, and transaction boundaries for multi-record changes.
3. The allowed lifecycle or state transitions, who may trigger each transition, which transitions are terminal or reversible, and what audit history must remain immutable.
4. Archive, retention, and deletion behavior, including what happens to dependent records and external files.
5. Idempotency strategy for submissions, jobs, imports, notifications, webhooks, or retries where applicable.
Use migrations rather than ad-hoc schema creation. Store time instants consistently and retain named timezone context whenever local schedules or dates matter. Never rely on a counter, disabled button, or client-side check to preserve a business invariant.
USERS, AUTHENTICATION, AND PERMISSIONS
Implement only the roles required by the stated audience. Make the ownership and visibility model explicit before coding. Enforce authorization in every server-side query and mutation, including search, exports, attachments, live updates, and guessed URLs—not merely by hiding controls. Use secure session defaults, protect state-changing requests, and provide an understandable signed-out, expired-session, and forbidden state. Seed distinct users when multiple roles are required so permissions can be demonstrated and tested.
INTERACTION AND VISUAL DIRECTION
The product should feel fast, calm, focused, and credible rather than like a generic admin template. Use a clear visual hierarchy, restrained color, readable typography, generous hit targets, and consistent placement for primary actions. Start with server-rendered HTML and progressively enhance only the interactions that benefit from it. The core workflow must remain understandable if enhancement fails.
Start with server-rendered Rails views and ordinary forms. Use Turbo for navigation, submissions, and server-driven updates, then Stimulus only for small browser-side behavior. Do not turn the product into a client-side SPA, and keep the core workflow usable when enhancement fails.
Design mobile layouts intentionally instead of simply stacking desktop panels. Support keyboard navigation, visible focus, semantic landmarks, explicit labels, useful page titles, reduced-motion preferences, and screen-reader announcements for asynchronous results. Never use color alone to communicate state. Destructive actions require clear scope and confirmation; safe repeated actions should be idempotent.
TECHNICAL DIRECTION
Build this version with Ruby on Rails and Hotwire: Turbo for navigation, form submissions, and server-driven updates, and Stimulus for small browser-side behavior. Use RESTful controllers with strong parameters and explicit authorization, with domain transitions in testable models or small application services. Use Active Record migrations plus database-level constraints and transactions; Active Storage with an S3-compatible service for private files; Active Job with a durable queue backend for retryable work; Action Mailer for email; and Action Cable only when live updates are required.
Keep domain rules in testable server-side modules instead of route handlers or UI components. Separate persistence, external providers, and background work behind small interfaces without building a framework. Prefer ordinary HTML forms and URLs for durable navigation; use optimistic interaction only when failure can be reconciled clearly.
The product brief currently identifies SwiftUI, Swift, macOS as capability context. Preserve any required native, browser-only, edge, storage, real-time, or background-processing capability through a narrow adapter appropriate to the selected framework. If the core workflow genuinely requires native or browser APIs, keep that runtime as the primary execution surface rather than simulating inaccessible capabilities or inventing an unnecessary web surface.
Integrate with macOS Accessibility API and local file storage. For every integration:
- List required environment variables in an .env.example without real secrets.
- Add a small adapter with timeouts, normalized errors, and a deterministic local fake or development path.
- Verify inbound signatures and deduplicate provider events where supported.
- Keep credentials server-side, encrypt long-lived provider tokens at rest, and redact secrets and sensitive payloads from logs.
- Define retry, backoff, and idempotency behavior for any side effect that can be repeated.
SECURITY AND PRIVACY
Process every keystroke locally and in memory only, never log or transmit typed text, and store nothing outside the local snippet library.
Validate, normalize, and length-limit all untrusted input on the server. Escape rendered content by default, sanitize any intentionally accepted markup, rate-limit public or abuse-prone actions, and use private object storage plus short-lived authorized URLs for sensitive files. Collect the minimum personal data necessary for the named workflow. Document retention and deletion behavior. Add specific protections for the riskier surfaces in this app, such as uploads, redirects, outbound requests, email delivery, OAuth, webhooks, CSV import or export, and real-time connections.
ACCEPTANCE SCENARIOS
Automate these app-specific scenarios at the most appropriate level:
1. Given the user types an abbreviation inside a disabled app, nothing expands and nothing about the keystrokes is retained.
2. Given a fill-in snippet is triggered, canceling the popup inserts nothing and leaves the typed abbreviation for the user to keep or delete.
3. Given {date+3d} appears in a snippet expanded on a Friday, the result contains the correct following Monday in the user’s locale format.
TESTING
Add focused unit tests for state transitions, authorization predicates, normalization, date or money calculations, and other risky domain rules. Add integration tests for persistence constraints and each external adapter’s success, timeout, retry, and rejection paths. Add at least one browser-level test for every end-to-end journey above, including one small-screen viewport. Tests must use isolated data and run through a documented single command.
OPERATIONS AND FAILURE RECOVERY
Add structured server logs with request, job, or event correlation IDs but no secrets or unnecessarily sensitive data. Make failures actionable in both the interface and logs. Background work must expose pending, succeeded, failed, and retrying states where relevant; do not silently swallow errors. Include safe database migration and rollback guidance, seed data, backup and restore notes, external-data cleanup behavior, and a basic health or diagnostic path appropriate to the stack.
DELIVERABLES
Ship the working application, migrations, representative seed data, tests, .env.example, and a concise README. The README must cover prerequisites, local setup, environment variables, migrations, seed and test commands, deployment, integration setup, backup and restore, security decisions, and known limitations. Seed data should exercise the happy path plus at least one empty, failed, overdue, expired, archived, or permission-restricted state relevant to the product.
DEFINITION OF DONE
The app is complete when a fresh developer can follow the README, create and migrate the database, run the app, sign in as each relevant role, complete every named journey using real persisted data, refresh without losing state, recover from common failures, and use the core interface on phone and desktop. All acceptance scenarios pass, permission boundaries are covered by tests, and no core screen is left as a placeholder.
NON-GOALS
Do not build cloud sync, team snippet sharing, a Windows or iOS port, or usage analytics of any kind.Build just one piece
Not ready to replace all of TextExpander? Fine. These are the peculiar sub-problems hiding inside it — the parts that are actually interesting to build. Each one is a standalone prompt, scoped to an evening, no strings attached to the full build.
The keystroke matcher with a memory of nine charactersA rolling buffer no longer than your longest abbreviation, and nothing ever hits disk.
Build the keystroke-matching core of a text expander. Watch system keystrokes through the platform accessibility APIs and detect when the user finishes typing an abbreviation like ;sig followed by a delimiter (space, tab, enter). The privacy constraint shapes the design: hold keystrokes only in a rolling in-memory buffer capped at the longest registered abbreviation plus one, evict from the front as characters arrive, clear the buffer whenever focus changes fields or apps, and never write a byte of typed text to disk or logs. Match on exact abbreviation plus delimiter, not on prefixes mid-word, so typing missing never fires a ;sig-like trigger embedded in it, and reset matching on backspace so half-typed triggers don't misfire later. When two abbreviations could collide, longest match wins, and the editor should warn at creation when one abbreviation is a prefix of another. Done when: abbreviations fire only on exact match plus delimiter, the buffer provably never exceeds its cap or leaves memory, and switching apps mid-abbreviation resets cleanly.
The replacement that happens all at once or not at allDelete the trigger, insert the snippet, park the cursor. No half-states in someone else’s text field.
Build atomic trigger replacement for a text expander. The user typed ;sig and a space into some arbitrary app's text field; you must delete those five characters and insert a multi-line signature, leaving the cursor at the end, and it has to work in fields you don't control. Prefer manipulating the focused element's value and selection through the accessibility APIs directly; where an app doesn't support that, fall back to synthesized backspaces followed by a paste-style insertion, saving and restoring the user's clipboard if you borrow it. Atomicity is the contract: if insertion fails partway, restore the typed trigger rather than leaving the field half-mangled. Fill-in placeholder snippets pause the pipeline for a popup; completing it inserts the finished text, while canceling inserts nothing and leaves the original abbreviation sitting in the field for the user to keep or delete. Done when: expansion lands correctly in at least three unrelated apps, the clipboard survives every expansion intact, and a canceled fill-in leaves the field exactly as typed.
The {date+3d} that knows Friday plus three is MondayA tiny date grammar, locale formatting, and month-boundary math that never lies.
Build date-math placeholders for a text-expander snippet engine.
Snippets contain tokens like {date}, {date+3d}, {date-2w}, {time}, and {date+1m:MMM d, yyyy}, resolved at expansion time. Write the small parser: base token, optional signed offset with day, week, month, and year units, optional explicit format string after a colon, with unrecognized tokens passed through literally instead of expanded wrongly, silent misexpansion is worse than none.
The calendar math is where correctness lives: offsets operate on calendar dates in the user's local timezone, not epoch arithmetic, so a +1d expansion at 11 p.m. before a DST change still yields tomorrow's date. Month offsets clamp sensibly, January 31 plus one month lands on the last day of February, leap years included. Default formatting follows the user's locale; explicit format strings override it. Show a live preview in the snippet editor of what each token resolves to right now.
Done when: {date+3d} on a Friday renders the following Monday, Jan 31 +1m clamps correctly in leap and non-leap years, and malformed tokens survive untouched.The expander that goes deaf near password fieldsSecure-input detection and per-app kill switches, default-deny where it matters.
Build the do-not-expand system for a text expander. Some places must never see an expansion: password managers, terminals, secure input fields. Two mechanisms, checked before any keystroke is processed. First, per-app rules: identify the frontmost application by bundle identifier and skip matching entirely, not just insertion, when it's disabled, so keystrokes in excluded apps are never even buffered. Ship with a default-deny list covering common password managers, and let the user toggle any running app from a rules screen. Second, secure-input detection: when the system flags secure text entry, as macOS does during password fields, suspend all keystroke observation for the duration, regardless of app rules. Surface state honestly in the menu bar, active, paused, disabled-for-this-app, so silence in a terminal reads as intentional rather than broken, and offer a global pause-all toggle. Done when: typing an abbreviation in a denied app expands nothing and buffers nothing, secure-input mode suspends observation systemwide, and the menu bar always tells the truth about why expansion is off.
Frequently asked questions
How long does it take to build your own TextExpander?
A basic version — expansion, placeholders, date math, per-app disable — takes about 10 hours. Roughly 3 days gets you a solid v1 with folders, quick-search palette, usage stats, backups. Matching everything TextExpander really does (team sharing, cloud sync, windows and ios apps) is closer to 3 months+, which is exactly why you should scope down instead.
How much does TextExpander cost if I keep subscribing?
TextExpander runs $4.16–$8.33 per month on public paid plans, which is $50–$100 per year. A focused self-built replacement costs your build time plus close-to-zero hosting.
What stack should I use to build a TextExpander alternative?
The build prompt on this page ships in four flavors: the AHA stack (Astro, HTMX, Alpine.js), Next.js, Laravel, and Ruby on Rails. The capability context for this product is SwiftUI, Swift, macOS. Pick the stack you already know — the scope matters more than the framework.
What features does a minimal TextExpander replacement need?
A useful v1 needs: abbreviation triggers that expand system-wide via the accessibility APIs; fill-in placeholders completed in a small popup before insertion; date math like {date+3d} for deadlines and follow-ups; per-app disable for password managers and terminals; a searchable local snippet library stored as a plain file. Everything else is scope creep until you personally miss it.
What should I deliberately not build?
Do not build cloud sync, team snippet sharing, a Windows or iOS port, or usage analytics of any kind.
Does this build also replace aText and Espanso?
Yes. TextExpander, aText and Espanso all solve the same core job — expand abbreviations into snippets anywhere on the system while every keystroke stays on the machine. The scoped v1 on this page covers what most people use any of them for, so one focused build replaces whichever you currently pay for.