Pourya Shahroudi
  1. Home
  2. Work
  3. La Bouchée

The online side of a bakery, run from a Raspberry Pi

La Bouchée is a made-to-order French bakery in Los Gatos. I built its website in December 2024 and have run the technical side of the business since. This is what runs, when it runs, and what it is allowed to do on its own.

  • Site: labouchee.us
  • Built December 2024
  • Runs on a Raspberry Pi at home

The site

A fast static site, with a page for each thing the bakery sells

labouchee.us is a static site I built by hand. Each product and service has its own page, there is a quote request form for orders, and every page carries structured data, so search engines and AI assistants read the menu correctly.

The site is the easy part. Keeping a small business found, listed and watched is a week of small chores that nobody has time for, so the rest of this page is about the jobs that do them.

The system

What it reads, what it does, and what comes out

Everything runs on a schedule on a Raspberry Pi at home: more than 20 jobs, with unit test suites that run in CI on every change. Each job reads from a Google service or the site itself, does one bounded piece of work, and leaves a result somewhere a person can look. Nothing customer-facing is published until a person approves it.

Reads from

  • Google Search Console
  • Google Merchant Center
  • Google Business Profile and its reviews
  • The site, its quote form and sitemap
  • Google's index of the site
  • California WARN notices and news searches
  • An AI assistant with web search
  • Competing bakeries' sites

Jobs on the Pi

  • Site watchdog every 30 minutes
  • Catalogue refresh and listing check daily
  • Index check daily
  • Review reader daily
  • Business Profile post drafter weekly
  • Corporate lead finder Fridays
  • Search review and page proposals monthly, 1st
  • AI assistant check monthly, 1st
  • Verdicts on page changes monthly, 15th
  • Competitor coverage quarterly

Leaves behind

  • Pull requests with proposed page changes, for review
  • Drafts of review replies and posts, waiting for approval
  • Verdicts on past changes: worked, no effect, or worse
  • Tickets when the site has a problem, closed on recovery
  • Lead lists of at most four employers a week
  • One health line per job per day
  • A message only when a person needs to act

The schedule

From every 30 minutes to once a quarter

Pacific time
..:..:..
Next job due
..

The cadence follows how fast each thing can change. A page going down matters within the hour; a search ranking takes weeks to move; a competitor's menu changes a few times a year.

JobCadenceNext runIn
Site watchdogKey pages, quote form, certificate, sitemapEvery 30 minutes
Google catalogue refreshMerchant CenterDaily 06:50
Listing checkPrice and availability against each pageDaily 07:10
Index checkEvery page still in GoogleDaily 08:20
Review readerA reply drafted for each new reviewDaily 09:30
Search ranking checkWith a summaryMondays 08:00
Business Profile post draftWith a product photoWednesdays 10:30
Corporate lead finderAt most four employersFridays 16:00
AI assistant checkA fixed set of customer questions1st of the month, 07:00
Search reviewSearch Console data read1st of the month, 07:30
Page changes proposedAs pull requests, for review1st of the month, 10:00
VerdictsOn changes live six weeks or more15th of the month, 09:00
Competitor coverageWhat their sites cover that this one does notQuarterly, 1st of Jan, Apr, Jul and Oct, 09:00
Schedule, not status

All times Pacific. The countdowns are computed in your browser from each job's cron expression. This page knows when a job is due, not whether it ran or what it found; that record is private, and the jobs send a message only when a person needs to act.

The jobs

Each one does a bounded piece of work

  • The search cycle

    Once a month an LLM agent reads Search Console and Google Trends data and proposes up to five site changes, each required to cite the data behind it. Code-level changes arrive as a pull request for a person to review and merge. On the 15th, a later job judges each page changed six weeks or more ago by its traffic before and after, with the rest of the site as the baseline, and marks it worked, no effect, or worse.

  • Google listings

    The Google Merchant Center catalogue is refreshed daily and each listing is checked against its page's price and availability. An LLM drafts a reply to each new Google review, and a weekly Business Profile post with a product photo and a link to the page. Nothing is published until a person approves it.

  • Monitoring

    A watchdog checks the site every 30 minutes: key pages, the quote form, the security certificate and the sitemap. A problem opens a ticket and recovery closes it. A daily check confirms Google still has every page in its index. The watchdog is plain Python with no LLM, since an agent can report success when the job under it failed.

  • Corporate leads

    Every Friday a finder suggests at most four large Bay Area employers for corporate dessert orders. Each one is first checked for layoffs, through California WARN notices, and for takeovers and legal trouble. A company that fails a check, or cannot be checked, is left out. An LLM picks from that vetted list and drafts a note for each company, and code rejects any lead naming a company outside the list or citing evidence that is not that company's. Sending stays manual.

  • AI assistants

    Once a month a fixed set of customer questions goes to Claude with web search, and to ChatGPT through the OpenAI API on demand. The answers are checked for whether La Bouchée is named, and where.

  • Competitors

    Once a quarter, the coverage of competing bakeries' sites is compared with La Bouchée's, and the differences are reported.

The LLMs

Where the LLMs sit, and what checks them

Wherever an LLM writes something, it only drafts, and a person approves before anything goes out. The watchdog uses no LLM at all.

  • Data
  • LLM
  • Code check
  • Person
  • Outcome

  1. Search

    Monthly
    1. DataSearch Console and Google Trends
    2. LLMProposes up to five site changes, each citing the data behind it
    3. Code checkDrops any proposal that cites no known trend term or site page, and keeps five at most
    4. PersonReviews and merges the pull request. Nothing merges or deploys by itself
    5. OutcomeThe change goes live on labouchee.us

    Checked laterSix weeks or more after a change, a job judges the page by its traffic before and after, with the rest of the site as the baseline. The verdict is worked, no effect, or worse.

  2. Corporate leads

    Fridays
    1. DataLarge Bay Area employers, each screened for layoffs through California WARN notices, takeovers and legal trouble. A company that fails a check, or can't be checked, is left out
    2. LLMPicks from that list and drafts a note for each
    3. Code checkRejects any lead naming a company outside the list, or citing evidence that isn't that company's
    4. PersonSending stays manual
    5. OutcomeAt most four leads a week

  3. Reviews and posts

    Daily and weekly
    1. DataNew Google reviews, and the products for the weekly post
    2. LLMDrafts a reply to each new review, and a weekly Business Profile post
    3. PersonNothing is published until a person approves it
    4. OutcomePublished on Google

  4. Watchdog

    Every 30 minutes
    1. DataThe site itself
    2. No LLM
    3. Code checkPlain Python. A problem opens a ticket and recovery closes it
    4. PersonA message goes out only when a person needs to act

    Why no LLMAn agent can report success when the job under it failed, so the job that watches the site is plain code.

Each row is one job, step by step. The dashed box is the LLM's draft, the heavy box is code with no model in it, and the highlighted box is where a person decides.

The line

What runs on its own, and what waits for a person

The rule is simple. Anything a customer could see is a draft until a person approves it. Anything that only keeps the machinery honest runs on its own.

Runs on its own

  • Refreshing the Google catalogue
  • Checking listings against their pages
  • Checking the site, the form, the certificate and the sitemap
  • Opening and closing tickets
  • Checking Google's index
  • Screening employers before they reach the lead list
  • Judging past page changes

Waits for a person

  • Every page change, reviewed as a pull request
  • Every review reply
  • Every Business Profile post
  • Every corporate lead, before anyone is contacted

Each job writes one health line a day, and a message goes out only when a person needs to act. A quiet day means every job ran and found nothing to report.

Turned off

The pipeline I measured and switched off

I also built an order pipeline. It read the business inbox, put each new order on the calendar, and had an AI agent mark it confirmed, declined or cancelled each night from the email thread.

I measured it against real outcomes and turned it off. Customers also confirm by text and Instagram, which the inbox never sees, so the agent was judging orders from a partial record.

The same two rules run through everything above. Each job is checked against what really happened, and a person approves anything a customer sees.

Next

Could your business use this?

If your business could use a setup like this, here is what I offer. My resume has the rest of my work.

[email protected]