Eight kinds of
work, done
properly
Described by what you get, not by the technology we would use to get there. The technology is our problem.
AI
Agents wired into your real data and your real systems, doing work a person would otherwise do by hand.
Most AI projects fail the same way. A demo works beautifully on five hand picked examples, then meets real data and falls apart. We build the unglamorous half. The retrieval that finds the right record. The evaluation suite that proves it still works after a change. And the human approval step for anything that spends money or touches a customer.
What that includes
- Agents that do a job end to end instead of chatting about it. Read the inbox, pull the order, draft the reply, wait for your yes
- Answers pulled from your own documents, contracts, tickets and product data, so it cannot make things up
- A safe connection between an AI assistant and your own systems. It can look things up and take actions without anyone handing it a password
- Evals and regression tests, so you find out a prompt change broke something before your customers do
- Guardrails against prompt injection, and hard limits on what an agent may do without a person confirming
- Model routing and fallbacks, so one provider having a bad afternoon isn’t your outage
- Cost controls: token budgets, caching and small models for the work that doesn’t need a large one
- AI agents
- Read, decide, act, and wait for your yes
- Your own documents
- Answers from your contracts and tickets
- Reliable AI
- Tests and limits, so a change can’t break it
The part people underestimateThe hard part is never the model. It’s context engineering: deciding exactly what the model sees, from where, and in what order. Get that right and a cheap model beats an expensive one wired up badly.
Apps
iPhone and Android, built, submitted, and kept alive through store review.
A mobile app is two problems. Building it’s the first. The second is getting it through Apple and Google review, then keeping it there while both companies change the rules every year. That’s the one that surprises people.
What that includes
- One codebase where that makes sense, native where it doesn’t
- Push notifications that arrive when they’re supposed to
- In app purchases and subscriptions through Apple and Google
- Offline behavior, because phones lose signal
- Store listing, screenshots, privacy declarations and the review itself
- iPhone and Android
- One codebase where that makes sense
- App review
- Listings, privacy answers, and the review
- In app purchases
- Subscriptions through Apple and Google
The part people underestimateWe build for review from day one. Account deletion in the app. Permissions requested at the moment they’re used. And a privacy declaration that matches what the app actually does. Retrofitting those after a rejection costs more than doing them first.
Games
Games for phones and for the browser, built and shipped like any other product.
A game is a product with a harder audience. It has to be fun in the first thirty seconds. It has to hold up on a five year old phone. And if people come back, it has to keep giving them a reason to. The build is the easy half.
What that includes
- Games for iPhone and Android, through store review like any other app
- Games that run in a browser, with nothing to install and nothing to download first
- Controls that work on a touchscreen and on a keyboard, not one bolted onto the other
- Saves and progress that survive a lost signal and a new device
- In app purchases and ads, if you want them, declared properly at review
- Live updates and events, so the game can change without shipping a new build
- Mobile games
- iPhone and Android, built and submitted
- Web games
- Plays in a browser, nothing to install
- Keeping it live
- Updates, events, and the parts that break
The part people underestimatePerformance is the whole game on a phone. A frame rate that dips on an older handset reads as the game being broken. Most of the work is making sure it never does.
Software
The system your business actually runs on, built to fit how you already work.
This covers three things that look different and are the same job. A product other people pay to use. A tool only your team touches. A single job done properly in a browser. All three come down to modeling how the work really happens, then building something that fits it.
What that includes
- Accounts, sign in, password resets and team invitations
- Subscription billing that handles failed cards, upgrades and cancellations
- One place for the data that currently lives in four places
- Permissions, so the right people see the right records
- Imports from whatever you have now, including the messy spreadsheet
- Connections to the systems you already pay for
- An audit trail, so you can see who changed what and when
- SaaS products
- Software other people pay to use
- Internal tools
- Replaces the spreadsheet you rely on
- Web apps
- One job, done properly, in the browser
The part people underestimateWe start by watching how the work is done today, not by asking what features you want. The feature list you would write in a meeting and the thing that actually costs your team four hours a week are rarely the same.
Ecommerce
Shopify apps, Shopify stores, and the search work that gets a store found.
Selling online is three problems wearing one coat. The store has to work. The software behind it has to keep up on a busy day. And people have to find it before any of that matters. We do all three, which is why the search half isn’t guesswork.
What that includes
- Embedded apps that match the Shopify admin, so staff need no training
- Webhooks and background jobs that keep up with a busy store
- The data deletion handling Shopify requires before an app can be listed
- Multi store support where you run more than one
- Themes and storefronts that stay quick with a real catalog behind them
- Product and category pages that both shoppers and assistants can read
- App Store submission, or a private app if it’s only for you
- Shopify apps
- What the app store doesn’t sell
- Shopify stores
- Storefronts that stay fast with a real catalog
- Ecommerce SEO
- Product pages people and AI can read
Written up in full Shopify SEO
The part people underestimateShopify apps fail review for data handling more than for anything else. We ask for the least data the app needs. We say why we need each piece. And the privacy plumbing the store requires gets built before we submit, not after somebody makes us.
Websites
Fast sites that people enjoy using and machines can read without guessing.
A website has two audiences now, and most sites are built for neither. People decide in seconds whether you look like you can do the job. Assistants decide whether there’s anything here worth repeating. A site can look expensive and say nothing either of them can use.
What that includes
- Pages that say plainly what you do, who it’s for, and where you do it
- Quick on a phone, on the worst connection your customer is likely to have
- Structure and markup that a search engine and an assistant can both read
- Writing that answers a real question instead of describing a service
- A redesign that keeps what was already working, when there is something to keep
- Accessibility handled as it’s built, so it works for everyone from day one
- Design and build
- A site that says plainly what you do
- Fast websites
- Quick on a phone, on a bad connection
- Redesigns
- For a site that looks fine and isn’t working
The part people underestimateSpeed isn’t a technical brag, it’s a conversion number. And it’s the one thing on this list you can measure the day it ships, which makes it the easiest promise to hold us to.
AEO
Answer engine optimization. Being named when your customer asks ChatGPT instead of searching.
Your customers have started asking assistants instead of searching. Ask one for the best roofer in town and it names a few companies. Whoever it names is quietly taking work from everyone it doesn’t. Doing well on Google does not get you into that answer.
What that includes
- Finding out whether any assistant names you today, and what it says when it does
- Writing answers clear and specific enough for an assistant to repeat with confidence
- Structure and markup that state plainly what you do, where, and for whom
- Getting mentioned in the places assistants actually read, which is not the same as chasing links
- Keeping the facts about your business consistent everywhere they appear
- Checking again over time, because the answers change
- What AEO is
- Answer engine optimization, explained
- AI SEO
- Ranking on Google doesn’t get you named
- AEO and SEO
- How they differ, why you need both
The part people underestimateAssistants repeat what they can verify. A page that makes a specific, checkable claim gets quoted. A page of adjectives about being passionate and results driven gives them nothing to work with, so your name never comes up.
SEO
Being the result people find when they search for what you sell.
Almost nobody is failing at search because their business isn’t good enough. They’re failing because their site never says plainly what they do, and because nobody has answered the questions their customers actually type. Both are fixable, and neither is a secret.
What that includes
- Finding out what your customers actually search, in their words rather than yours
- Fixing the pages you have before writing new ones
- The technical work: speed, structure, and making every page reachable
- Pages that answer one real question properly, instead of many that answer none
- Local search, so people close enough to buy from you can find you
- Plain reporting on where you show up, and what moved
- Local search
- Found by people close enough to buy
- SEO for your trade
- A law firm isn’t a dentist
- Answering questions
- The pages that earn the search
Written up in full Las Vegas SEO, SEO for law firms, Shopify SEO
The part people underestimateRanking for your own company name isn’t a result, it’s a baseline. The number that matters is whether someone who has never heard of you finds you while they’re deciding who to call.
Every lane, same standard
The screens your team lives in get the same care as the front page.
Internal software has a reputation for being ugly because it’s usually built once by whoever was free. We don’t build that way. Spacing on a grid. One obvious next action. Plain words instead of system jargon. And it works on a phone, because half your team isn’t at a desk.
How a project runs
We agree the scope in writing first
What gets built, what it costs, what it doesn’t include, and when it’s done. If you want something outside that later, we quote it and you decide. We don’t add work and then invoice for it.
You see it working every week
You click the working software every week, and tell us what’s wrong while it’s cheap to change. Course corrections are cheap in week two and expensive in month four.
You own everything
The code, the repository, the hosting accounts, the domain. On full payment it’s yours, including the source. If you want to take it elsewhere, you can, and we’ll hand it over cleanly, with everything documented.
We stay if you want us
Software needs someone to keep it alive: dependency updates, platform changes, the occasional fire. We can do that, or hand it to whoever will. Both are a fine outcome.
The vocabulary
Every term you’ve been hearing, in plain English
Our industry generates jargon faster than it generates working software. We keep a list of what the current vocabulary actually means, and whether it matters for you. If a vendor uses one of these words without being able to explain it this plainly, that tells you something.
What we turn down
A studio that says yes to everything is telling you something. Here is what we say no to, so you don’t waste a conversation finding out.
- Work where the plan is to hire us and then not talk to us for two months.
- A rewrite of a working system because a new framework came out.
- Something a product you can buy already does well. We’ll tell you which one.
- Anything where the point is to hide from customers what the software does with their data.
- A fixed bid on a scope nobody has thought through. We’ll help you think it through first.
We take on a small number of outside builds a year, because the rest of the time we are building our own products. That’s the honest constraint. It also means when we take something on, it gets real attention.
Where to start
Not sure which of these you need?
That is a normal place to start. Describe what is going wrong and we will tell you which one it is, or that it is none of them.