01

AI assistants on your own data

The problem

The answer to an everyday question is usually split across a few apps, a data warehouse, and a stack of documentation. "What does next month look like?" means knowing which screen to open, or asking the one person who already knows.

What we build

We put an assistant inside the tools people already use. It can read the documentation, query live application data, and use curated warehouse views. Answers come back as tables and charts in the conversation, and the steps the assistant took stay visible so someone can check the sources.

A real example

Spike is the assistant on the Color Orchids platform, named for the orchid spike, the flower stem growers count. Staff ask a question the way they would in any chat tool. Spike answers from the platform docs, live reservations, and warehouse history. Asked about next month's reserves, it returns a weekly breakdown, the customers driving volume, and a chart. Sessions are kept so people can come back to their own conversations.

See the Spike project · How Spike is built

02

Operations and custom apps

The problem

Reservations, inventory, purchasing, transfers, and shipping often live in separate spreadsheets. Counts that happen on a greenhouse floor or a packing line are even further from the system of record, so the numbers drift before anyone can report on them.

What we build

We build custom web apps, including phone-friendly ones, on a single shared data layer. Each screen is shaped around the work: recurring orders, a searchable plant list, a photo of what to pack. Because every app writes the same well-defined data, reporting and an assistant can use it later without a second cleanup project.

Real examples

• Operations platform. Reservations, customer items, inventory, logistics, and purchasing for a grower that ships to retail customers. Open the project
• Staking app. A phone-friendly app for counting flower spikes on the greenhouse floor, with variety photos and a warning when a grow year looks wrong. Open the project
• Losses app. Mobile tracking for plant losses by location, week, variety, and reason, so inventory stays close to what is actually on the bench. Open the project
• Plant item viewer. Photos and the item recipe so packing staff can assemble each customer item without leaving the line. Open the project

03

Data pipelines, dashboards, and reporting

The problem

A report that someone rebuilds every week goes stale, and two spreadsheets rarely agree. Managers end up waiting on a person instead of looking at a number they trust.

What we build

We build pipelines that take operational data into a warehouse, then into dashboards and into the spreadsheets a team already knows how to filter. The apps are designed so the data lands cleanly the first time. Scheduled jobs refresh snapshots, views, and sheets. QuickBooks and other sources can come in on the same schedule.

A real example

On the Color Orchids platform, reporting follows from the same data the apps write. The portfolio shows profit margin year over year, reserve profit and counts by week, sales invoices loaded from QuickBooks, freight cost and cost per pallet, logistics cost by customer, and a vase inventory spreadsheet filled in from the apps. That same warehouse is one of the sources Spike reads.

See the reporting that came out of the platform

04

Cloud cost and modernization

The problem

A client's nightly data work ran on Apache Airflow. The cluster to run it properly cost about $1,000 a month. Other schedulers were still too expensive for the need. The jobs were not the expensive part. The always-on cluster was.

What we build

We build schedulers and services on Google Cloud and Cloud Run that run when there is work. A job definition can have many schedules. Jobs can start follow-on jobs, with the lineage visible. Runs can be started by cron, by hand, or through an API, and the logs stream back to the browser.

A real example

The Cloud Run scheduler replaced that Airflow cluster. It runs reliably every night and several times a day, about 110 jobs a day, for around $30 a month. It also powers the scheduled data loads, snapshots, and spreadsheet refreshes behind the Color Orchids reporting.

See the Cloud Run scheduler · How the scheduler runs on Cloud Run

How we work

Discovery, build, then handoff

Engagements are scoped around a real workflow, not a menu of capabilities. The people who learn the work are the people who build the system.

1. 1

   Discovery

   We start with the questions your team actually asks and the tools they already use. That is usually a working session on the workflow, the spreadsheets, and which numbers have to be trusted.

2. 2

   Build

   We build a usable slice against your real data, then widen it. Apps, pipelines, and assistants are designed together so reporting is part of the first version, not a follow-up project.

3. 3

   Handoff and support

   You get the running system and the documentation to operate it. We stay available for the questions that come up as your team takes it over.