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
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
Algolia Index Sync
Algolia Index Sync
Keep the search index matching the database, including who is allowed to see what.
What it does
A sync pipeline that mirrors records into a search index with tenant-scoped filters and scheduled reconciliation.
How it works
- 1 Identify every record type that should be searchable and define one index document per record, keyed by an identifier that never changes for the life of that record.
- 2 Push changes through the app's existing background-job system on create, update, and delete, and make every write idempotent so a replayed job produces the same document rather than a duplicate.
- 3 Put tenant, workspace, and visibility values on each document as filter attributes, and have the server issue short-lived scoped search credentials that pin those filters. The browser must never choose its own filter.
Copy the prompt
No account needed
Add this feature to my app:
https://addthisfeature.com/x/algolia-index-sync
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
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.