Listen to this blog as a podcast:

For over a decade, the modern SaaS setup has looked something like this:

1. Pick your stack. Skim the docs.

2. Sign up to five different tools (maybe more).

3. Verify your email. And wait… (check spam, click resend, repeat).

4. Copy-paste API keys (which one’s the secret again?)

5. Realise one of them is wrong. Go back. Fix it.

6. Tinker until something works.

It’s not difficult. It’s just… tedious.

Introducing Stripe Projects

Our friends at Stripe are on a mission to fix this with Projects. In a nutshell, it’s a way to provision and manage your app’s infrastructure (increasingly a cocktail of third-party tools and vendors) all directly from the terminal.

It’s a small, but very meaningful shift; less context switching, fewer manual steps, and a setup process that’s easier to repeat when you start the next project.

Algolia is now part of this ecosystem. 

In this post, we’ll look at how this works with Algolia, and how you can carry the workflow through to using the Algolia CLI to go from setup to a working search experience, all from the terminal. 

Let’s get into it.

Setting up Stripe Projects

Before you begin

Before you can add Algolia, you’ll need to be signed up with Stripe, and have Stripe CLI authenticated in your terminal of choice. Stripe has a handy guide on getting that set up here.

Installing the Stripe Projects plugin and initialising your project

If you haven’t already, start by installing the Stripe CLI “Projects” plugin:

stripe plugin install projects

This adds a new set of stripe projects commands to your CLI. Conceptually, it’s an enabling layer that understands how to provision and manage third-party services as part of your project, and returns the necessary keys (per provider) into your .env file.

From within your repository, we can now initialise a new project:

stripe projects init

Under the hood, this adds project-level metadata and configuration to your repo so the CLI (and any agents you use later) understands:

• what providers have been provisioned

• how resources are managed

• how credentials should be handled

If you wish, you can browse the plethora of providers and services that are compatible with Projects (Algolia included!) using:

stripe projects catalog

Each item represents a service that can be provisioned and wired into your project without leaving the CLI. Most providers (if not all) have either a free or paid offering to suit your requirements.

Provisioning Algolia via Stripe Projects

Now that we have Projects set up, let’s talk about how to provision Algolia. To do this, it’s as simple as using:

stripe projects add algolia

This triggers the provisioning flow. It’ll ask you a few questions along the way, such as your preferred hosting region, and plan (free or pay-as-you-go). Once provisioning completes, your repository is updated with the necessary configuration to use Algolia immediately. 

On your behalf, Stripe CLI has:

• Created an Algolia account and application, without needing to verify your email again.

• Handled your chosen subscription and any billing details where applicable.

• Generated the necessary API credentials.

• Wired those credentials into your project’s .env file:

  • ALGOLIA_APPLICATION_ID

  • ALGOLIA_APPLICATION_NAME

  • ALGOLIA_SEARCH_API_KEY

  • ALGOLIA_WRITE_API_KEY

• Updated your local project configuration to recognise Algolia as a provisioned provider.

That’s it! We have now established a real, production-ready Algolia backend that your app can talk to.

From here, there are further general lifecycle commands available via the Stripe CLI, such as upgrading, downgrading and rotating the keys of existing vendors. Run stripe projects –help for more.

Handing off to an agent

The rest is application-specific, and that’s where it makes sense to bring in an agent.

To help, we’ve prepared some tried-and-tested prompts for these tasks. For many providers, Stripe CLI will have also pulled down any provider-relevant skills into the relevant folder structure in your repo. Algolia’s additional Skills repo may also prove handy!

Step 1: Push your data

With your project provisioned, the next step is to push (and ongoingly sync) your data to your new Algolia application.

You are a software engineer working on an existing codebase. Your task is to implement Algolia indexing in a way that fits the current architecture.

Before writing any code:

1. Inspect the repository and understand:
   - the backend architecture
   - where data is created, stored, or synchronised
   - any existing pipelines, jobs, or APIs responsible for data flow

2. Check whether this project can use an existing Algolia integration or connector:
   https://www.algolia.com/doc/integration.md

If a suitable integration exists:
- explain which one applies and why
- outline how it would be introduced into this codebase

If not:
- identify the language/framework used
- select the appropriate Algolia API client:
  https://www.algolia.com/doc/libraries/sdk/install.md

Do not write code yet. First:
- summarise your understanding of the system
- propose a clear, minimal plan for adding indexing
- state assumptions explicitly
- ask clarifying questions using your question tool to the user if anything is unclear or ambiguous

Then implement a minimal, idiomatic indexing setup that:
- sends relevant application data to an Algolia index
- uses credentials already available via environment variables (.env)
- uses environment-aware index naming (for example dev, staging, and prod)
- integrates with existing data flows rather than duplicating them

Constraints:
- avoid large refactors
- keep changes small, safe, and easy to review
- follow existing project conventions

After implementation:
- explain how indexing is triggered (for example on write, batch job, or script)
- describe how to run or test indexing locally
- explain how to verify that records are correctly indexed in Algolia

Once your indexing logic is in place, you’ll typically want to run an initial bulk import to populate the index with existing data before relying on ongoing sync.

How you do this depends on your stack, but common approaches include running a one-off script that reads from your database and pushes records to Algolia, or even just exporting to JSON and importing in batches.

You can also ask your agent to do so: “run an initial data export to the Algolia connection we just implemented”.

Prompt 2: Tune your relevance settings

Once data is flowing, the next step is deciding how that data should behave in search.

Which fields should users be able to search? What should influence ranking? What should be filterable? Historically, this is where setting up Algolia required a steeper learning curve, and in turn became more time-consuming.

A better approach is to start with a conservative first pass based on the actual indexed schema, then refine from there. An agent can help here too, provided it works from real schema, explains its assumptions, and seeks clarification when the field meanings or priorities are unclear.

Install the Algolia CLI (Windows and Linux alternatives are available):

brew install algolia/algolia-cli/algolia

Then, run a “generative relevance” prompt (courtesy of the Generative Relevance CLI by Principal Software Engineer, Sarah Dayan):

You are a software engineer working on an existing codebase. Your task is to review the indexed record schema and apply a safe first pass of Algolia index settings using the Algolia CLI.

Before making any changes:

1. Inspect the codebase and the indexing implementation. 
2. Leverage the Algolia CLI to inspect sample records from the index to understand schema.
2. Identify:
   - which index or indices are being written to
   - the shape of the indexed records
   - which fields are consistently present
   - which fields are text, numeric, boolean, categorical, or date-like
3. Verify which fields actually exist in the indexed records before proposing any settings.

Do not apply settings yet.

First, produce a proposal covering:
- searchableAttributes
- customRanking
- attributesForFaceting
- optional sortable attributes or replicas, only if they are clearly useful

Follow these rules:

Searchable attributes
- include fields users are likely to search directly, such as names, titles, brands, categories, tags, and short descriptions
- exclude IDs, URLs, booleans, internal metadata, and purely numeric fields
- order attributes by likely importance
- only group attributes together if they are genuinely equal in importance

Custom ranking
- use fields that represent quality, popularity, freshness, or business value
- avoid weak or noisy signals
- use desc(...) when higher values should rank higher
- use asc(...) only where lower values are clearly better
- if no credible ranking fields exist, say so rather than inventing weak ones

Faceting
- include fields users would realistically filter on, such as category, brand, type, availability, or similar categorical fields
- avoid fields that are unique, long text, or clearly unsuitable for filtering
- use searchable(...) only where facet value search would genuinely help
- use filterOnly(...) only for programmatic filters not intended for display

Sortable attributes or replicas
- only propose sortable fields if they are clearly useful in the product experience
- keep this conservative, since sorting often requires replicas
- if sorting is not obviously needed, omit it

Do not write code or apply CLI changes yet. First:
- explain your reasoning briefly and concretely
- list assumptions
- ask clarifying questions using your question tool to the user if business intent, UX, or field meaning is ambiguous
- wait for approval before applying changes

Once approved:
1. Use the Algolia CLI to apply the chosen settings to the correct index.
2. Keep changes minimal and easy to review.
3. Show the exact commands used.
4. Explain how to verify the settings locally and in Algolia.

Constraints:
- do not invent fields that are not present in the indexed schema
- do not make large refactors
- do not assume every numeric field should affect ranking
- prefer a safe first pass over an aggressive configuration

Prompt 3: Implement your UI

We now have records indexed and our first pass of relevance is in place. The final step is the frontend implementation of the search UI itself.

By now, the agent has enough context to build against something real: an index with actual data, sensible settings, and a clearer idea of what users should be able to search and filter.

You are a software engineer working on an existing application. Your task is to add a search experience powered by Algolia that fits naturally into the current frontend architecture.

Before writing any code:

1. Inspect the frontend (or full-stack) structure and understand:
   - the framework being used
   - how components are organised
   - how data fetching and state are handled

2. Choose an appropriate search UI approach for this stack:
   https://www.algolia.com/doc/ui-libraries.md

Do not write code yet. First:
- summarise your understanding of the UI architecture
- propose a minimal implementation plan for adding search
- state assumptions explicitly
- ask clarifying questions using your question tool if any UX, routing, or data flow is unclear

Then implement a minimal but polished search experience:
- a query input
- a results list
- basic UX states such as loading and empty results
- any faceting and filtering required, based on the use case and indexed schema

Ensure the implementation:
- uses Algolia credentials already available via environment variables (.env)
- follows existing project conventions and patterns
- integrates cleanly with the current UI and routing
- avoids unnecessary complexity or new abstractions

Constraints:
- keep the implementation simple and extensible
- do not introduce large structural changes unless necessary

After implementation:
- explain how to run and test the search locally
- describe how to verify queries and results are working correctly

Wrapping up

Instead of jumping between dashboards, signing up to services, and wiring everything together manually, the entire setup happens in a single, repeatable flow. Stripe Projects handles the plumbing. Algolia handles search. The rest becomes a much more focused exercise in shaping and tuning your application, rather than assembling it.

Is it fully “hands-off”? Well, not quite, and that’s a good thing. You still decide what data to index, how relevance should behave, and what the user experience looks like. But the heavy lifting around setup, integration, and boilerplate largely disappears.

If you’re starting a new project, it’s worth trying this workflow end-to-end. The difference isn’t what you build, but rather how little time you spend on scaffolding over building what’s valuable.

Ready to see it in action? Watch the video below on Stripe CLI + Algolia.