Typesense Index Sync
Keep a search index in step with your records so results stay current and correctly scoped.
What it adds
A one-way sync from the app's records into a Typesense collection, with server-enforced tenant filtering and a rebuild path.
What your agent is told to do
5
What your agent is told to do
5-
1
Identify every model users search today and declare the indexed shape explicitly: the fields people type into, the fields they filter and sort on, and nothing more. Treat a missing or newly added field as absent rather than letting the document fail validation.
-
2
Reuse the app's existing background-job system to push creates, updates, and deletes. Do not index inside the request cycle; a slow or unreachable search service must never make a save fail or hang.
-
3
Build the tenant, workspace, and permission filter on the server at query time and attach it to every search. Do not accept a filter, collection name, or scope value from a client-supplied parameter, because anything the browser can set the browser can change.
-
4
Support a full rebuild that populates a new collection and only then switches the alias the app reads from, so queries keep hitting the old collection until the new one is complete and verified.
-
5
Meilisearch Index Sync solves the same problem for a different engine. Choose one engine and route all indexing through it; running both over the same records doubles the write path and guarantees the two drift apart.
Edge cases it handles
8
Edge cases it handles
8- The indexed schema will change. Handle optional fields, fields added after the collection was created, and fields that change type, by validating each document against the current shape and quarantining the ones that do not fit rather than aborting the batch.
- Tenant scoping must be applied where the query is assembled on the server. A filter passed through from the client, or merged with a client-supplied filter string, lets one customer read another customer's records.
- Indexing must be idempotent. The same update delivered twice, or a delete that arrives before the create it supersedes, must leave the index in the same correct state, so key documents by the record's stable identifier and carry a version or updated-at value to reject stale writes.
- A rebuild must not blank out search. Index into a separate collection, verify the document count and a sample of queries, then swap the alias, and keep the previous collection long enough to swap back.
- Records too large for the provider's document limit, or carrying values the schema rejects, must be truncated to their searchable text and logged as skipped rather than retried forever in a poison-message loop.
- The search service will be unavailable at some point. Fall back to a plain database query with a visible notice that results may be limited, rather than showing the user an empty result set that reads as no matches.
- Rate limits and bulk import throttling need exponential backoff with jitter and a bounded retry count, so a backlog after an outage does not amplify into a second outage.
- A record that becomes private, is soft-deleted, or moves to a workspace the user cannot see must be removed or re-scoped in the index immediately, since a stale index entry leaks a title and a snippet even when the detail page is protected.
Definition of done
9
Definition of done
9- Creating, updating, or deleting a record is reflected in search results without a manual reindex.
- Indexing runs in the background and a search-service outage never fails or delays a save.
- Tenant and permission filters are applied server-side and cannot be altered by a client parameter.
- Replaying the same indexing job produces an identical index state, and stale writes are rejected.
- A full rebuild completes with no observable search downtime and can be rolled back.
- Oversized or invalid documents are skipped with a logged reason instead of blocking the queue.
- When the search service is unreachable, the app degrades to database-backed results with an explicit notice.
- The feature matches the existing design system.
- No existing functionality is broken.
Related features
Mapbox Geocoding
Mapbox Geocoding
Convert typed locations into coordinates and structured addresses the app can use.
What it does
Forward and reverse geocoding with confirmed matches, controlled result bias, and coordinate precision rules.
How it works
- 1 Separate the two directions explicitly: text to coordinates for entry and search, coordinates to address for a dropped pin or a device location. They take different inputs, carry different confidence, and fail differently.
- 2 Present ambiguous matches as a list the user confirms. Silently taking the first result is how a record ends up in the wrong country with nobody noticing for months.
- 3 Bias results toward a location only when the app genuinely knows one, such as a workspace address or the map viewport the user is already looking at.
Copy the prompt
No account needed
Add this feature to my app:
https://addthisfeature.com/x/mapbox-geocoding
Contentful Entry Sync
Contentful Entry Sync
Create and update Contentful entries against the connected space, environment, and locale.
What it does
A sync that writes app records into Contentful entries using the connected space's content model and locale configuration.
How it works
- 1 Have the operator select the space, the environment, and the default locale during connection, and store all three, because writing production content into a sandbox environment is an easy and expensive mistake.
- 2 Fetch the content model at connection time and again before each sync run, map app fields to entry fields by their stable identifiers, and validate the value type against the model before attempting the write.
- 3 Write every localized field under an explicit locale rather than relying on whatever the space treats as default, and state clearly which locales the app owns and which it leaves to editors.
Copy the prompt
No account needed
Add this feature to my app:
https://addthisfeature.com/x/contentful-entry-sync
Google Places Address Lookup
Google Places Address Lookup
Turn a half-typed address into a structured location the app can rely on.
What it does
An address autocomplete that fills structured location fields from real places and stays editable by hand.
How it works
- 1 Replace free-text address entry on the forms that need a real location with a lookup returning structured components, and keep every component field editable after the lookup returns.
- 2 Group the keystrokes of one lookup into a single billable session and close it when a place is chosen or the field is abandoned. Debounce input and set a minimum query length, because every keystroke that reaches the provider costs money.
- 3 Store the provider's place identifier in its own field, separate from the human-readable address the user sees. The two serve different purposes, and the display text must never be parsed back into structure.
Copy the prompt
No account needed
Add this feature to my app:
https://addthisfeature.com/x/google-places-address-lookup
How it works
-
1
Copy the link
Grab the Markdown instruction URL for this feature.
-
2
Give it to your AI
Paste it into Claude Code, Cursor, v0, Lovable — whatever you build with.
-
3
It inspects, then implements
Your agent reads your existing app first, then adds the feature to fit it.
Works with your stack
These instructions are written to adapt. They tell the agent to detect your framework, match your existing design system, and reuse what you already have — rather than assuming a particular stack.
Need it tighter than that? Customize the feature and tell it exactly what you're running.