A company's story can be told by a series of SQL queries.

When things are working, failing, scaling or shrinking — all told from some queries. Better hope they're simple and clear, right?

To make those queries simple and clear, before writing or generating any code for a software product, you should design the SQL queries that you'll use to measure your product's success, and in turn success for your business.

These queries become the foundation for all kinds of things like pricing, billing/invoicing, operational metrics, product analytics, customer health, etc. — these are your "core company queries" or CCQs.

CCQs, when designed well, will serve you for years; designed poorly, they'll likely make your work annoying as hell and incredibly opaque. CCQs become the things that help you identify the right and wrong knobs to turn in your business that create revenue, momentum, and learnings.

The process for figuring these out only takes a few hours. Sketch the schema those queries imply, and pressure-test it:

• Do these queries map to all the valuable entities we might create?
• How will these queries scale over time?
• Are there too many tables or entities we're considering? Could some be compressed, simplified, or broken down and put back together?
• Is this design something we can partition easily?
• Are all the right relationships in place so we can properly run numbers on any cadence and slice we might prefer or want to explore?

For example, let's say we're building a ticketing platform. Users buy tickets to live music events, and events happen at venues.

The entities practically name themselves in this example: users, venues, events, tickets. Before writing any product code, sketch the queries you know you'll run for the foreseeable future, especially ones your stakeholders care about:

How much money did we make in the last 30 days?

select sum(price)
from tickets
where created_at > now() - interval '30 days';

Which venues drive revenue?

select venues.name, sum(tickets.price)
from tickets
join events on events.id = tickets.event_id
join venues on venues.id = events.venue_id
group by venues.name;

Are buyers coming back?

select user_id, count(*)
from tickets
group by user_id
having count(*) > 1;

Ten minutes of this and we've already made some key schema decisions: price lives on the ticket, tickets point to events, events point to venues. The queries designed the schema. This will also give agents and interns clarity when you ask them to start writing code too!

When setting up these kinds of initial conditions for software systems, don't worry about perfectly following third normal form or whatever. The important part is creating a rich, clear, and simple schema in your database, making it easy for teams of humans and agents alike to analyze and execute on for years to come.