Bootstrapping a Publishing Platform with AI: The Operating Lessons

Bootstrapping with AI is not a shortcut around thinking. It is a different way to turn domain knowledge into a working system.

I knew publishing before I knew software. I understood the recurring work: shaping concepts, coordinating production, maintaining quality, preparing assets, and getting books into readers' hands. What I did not have was a conventional engineering background or a development team.

AI changed the learning curve. It let me examine one problem at a time, ask questions in the context of the system I was building, test the answer, and return with evidence when the answer failed.

That loop became the foundation for Teneo.

Start With the Operating Problem

The first mistake in AI-assisted development is starting with code.

Code is downstream of the operating model. Before building anything, write down:

What repeatedly slows the work down?
Which decisions need the same context every time?
Where does quality become inconsistent?
Which handoffs lose information?
What should remain under the operator's control?

For publishing, the problem was larger than manuscript generation. A useful system had to connect the idea, book, brand, catalog, storefront, and the next product.

That is why Teneo is designed as a publishing system rather than a single-purpose text generator.

Use AI as a Teacher With a Working Surface

AI becomes more useful when every explanation can be tested against a real artifact.

The practical loop is simple:

Describe the behavior you need.
Ask the model to explain the smallest implementation that could prove it.
Build that slice.
Run it.
Bring the error, output, or screenshot back into the conversation.
Ask what the evidence changes.

This is different from asking a model to produce an entire application from a prompt. The system grows through inspected decisions, not one large act of generation.

Context Is the Real Development Environment

Models do not automatically understand the whole product. They need the same things a new team member needs:

The product's purpose.
The current architecture.
The contracts between components.
The definition of a valid output.
The known failure modes.
The test that proves the change worked.

When this context lives only in chat history, it disappears. When it lives in source-controlled specifications, tests, fixtures, and operating documents, it compounds.

The quality of AI-assisted development is therefore constrained less by typing speed than by context architecture.

Verification Is Part of Creation

AI can produce plausible code that is wrong in ways that are difficult to see from the code alone.

The answer is not merely a better prompt. It is a tighter evidence loop:

Build the real artifact.
Run the real workflow.
Inspect the finished output.
Compare it with an explicit acceptance contract.
Fix the earliest point where reality diverges from the contract.

For a publishing system, this means reading the generated book, inspecting the cover and formatted files, checking the storefront, and walking the customer path. A successful model call is not the product.

Build Reusable Rails, Not Repeated Demos

A prototype proves that something can happen once. An operating system makes the result repeatable.

The reusable parts matter most:

Identity and access.
Project context.
Generation orchestration.
Quality checks.
Asset storage.
Catalog structure.
Storefront and delivery.
Observability when a step fails.

Every shared rail reduces the amount of product-specific work required for the next publishing workflow.

Keep the Operator in Control

AI-assisted software should increase the operator's control over the work, not create a new dependency they cannot inspect.

That means preferring systems where:

Inputs and outputs are portable.
Important decisions are visible.
Failures are explicit.
Quality can be checked independently.
The customer relationship is not trapped inside a single marketplace.

This principle shaped Teneo's focus on the press around the book: the catalog, brand, storefront, and repeatable production system.

What I Would Do Differently

If I were starting again, I would make four choices earlier:

Write the contracts first. Define the output before asking AI to create it.
Build smaller vertical slices. Prove one complete path before expanding the surface area.
Save decisions close to the code. Do not make future sessions reconstruct the product from scratch.
Read the finished artifact sooner. Integration failures hide behind passing unit tests.

These practices are less dramatic than generating an application in one sitting. They are also what turns AI-assisted building into an operation that can survive the next session, model, or product.

The Practical Takeaway

Domain expertise is executable context waiting to be structured.

If you deeply understand a workflow, AI can help you interrogate it, formalize it, and turn it into software. The durable advantage comes from the combination:

Human judgment about the problem.
Persistent context about the system.
AI-assisted implementation.
Deterministic verification against reality.

That is the operating method behind Teneo.

Inspect What the System Produces

The best way to evaluate a publishing system is to read its output.

Explore the sample library →

Travis Eric

Founder, Teneo