Why I am building reusable base prompts for app architecture

Nikos Katsikanis - May 4, 2026

I made a new public repo called base-prompt-architecture.

The idea is simple: I am tired of having the same architectural conversation with AIAcronymArtificial intelligence. I use AI to mean software systems that can generate, classify, reason over, or transform information from prompts and data. every time I start an application.

I want user sign-up. I want an admin section. I want Remix. I want TypeScript. I want Postgres-shaped data. I want a cheap path before the minimum viable product, or MVPAcronymMinimum viable product. I use MVP to mean the smallest useful product version that can test whether the idea has real demand., makes money. I want a real testing story. I want good architecture without spending the first hour explaining the same baseline again.

That repetition is a signal. If I keep telling the agent the same rules, those rules probably belong somewhere reusable.

The repo is small on purpose

Right now the repo has one important file: base/remix3-aws-platform.md.

It is not trying to be a prompt marketplace. It is a base prompt for one platform shape: Remix 3, TypeScript, AWSAcronymAmazon Web Services. I use AWS to mean Amazon’s cloud platform for compute, storage, networking, databases, deployment, and managed infrastructure services., AWS CDKAcronymCloud Development Kit. I use CDK to mean defining cloud infrastructure in a programming language instead of only using hand-written templates or console changes., Cognito, SESAcronymSimple Email Service. I use SES to mean Amazon’s managed email sending service., Playwright, screenshot validation, and a PostgreSQL-compatible data model that can move to RDSAcronymRelational Database Service. I use RDS to mean Amazon’s managed relational database service, including managed PostgreSQL deployments. later.

That is a deliberately opinionated stack. I would rather have one sharp baseline than a vague prompt that tries to support every possible architecture.

A base prompt is not a vibe prompt

A weak prompt says “build me a modern app” and then hopes the agent guesses the rest.

I do not want that. I want the base prompt to act more like a small engineering contract.

It tells the agent the kind of code I expect: production-quality, strongly typed, maintainable, modular, and not built around throwaway schema. It says to keep domain logic out of interface components. It says to use explicit statuses, migrations, and constraints. It says not to build speculative features just because the agent can imagine them.

The point is not to make the agent clever. The point is to make the agent less random.

Platform rules and product requirements are different things

This is the distinction I want the repo to enforce.

The base prompt defines the platform. The app prompt defines the product.

If I am building an association membership app, the app prompt should talk about members, chapters, renewals, event access, permissions, and admin workflows. It should not have to repeat “use TypeScript,” “design for Postgres,” “write route-level tests,” and “do not put business logic inside interface components.”

When those concerns are mixed together, the prompt gets noisy. Worse, the product requirements get buried under generic architecture instructions.

The concrete example: low-cost now, Postgres later

The most useful rule in the current base prompt is probably the database rule.

I often want to save money before the product proves itself. I do not want an expensive always-on database just because I am still testing an idea. But I also do not want the agent designing around a temporary non-relational store in a way that makes the later move painful.

So the base prompt says the first deployment can be modest, but the schema, migrations, and repository layer should stay PostgreSQL-compatible from day one.

That is the kind of instruction that belongs in the baseline because it affects everything: identifiers, relationships, constraints, reporting, cleanup, imports, exports, and future integrations.

A cheap first version is fine. A structurally dishonest first version is not.

The delivery sequence matters too

The repo also defines the order I want the agent to work in.

I do not want it jumping straight into implementation. I want architecture first, schema second, critique third, refinement fourth, and implementation after that.

That sequence catches a lot of bad AI-assisted work before it becomes code. The agent is fast, but speed is not useful if it confidently builds the wrong shape.

I want the thinking to become visible before the files start changing.

Testing belongs in the baseline

The base prompt includes Playwright and route-level screenshot validation because “it compiles” is not a serious finish line for web applications.

I want real flows tested: public pages, sign-up, member areas, admin areas, and the visual states that break when an agent makes broad changes.

Screenshot validation matters because AI-generated frontend changes often fail in boring ways: blank routes, broken layouts, unreadable screens, and missing states.

Those problems are not glamorous, but they are exactly the kind of thing I want the baseline to catch.

This is really about making prompts boring

The more I use agents, the less interested I am in magical prompts.

I want reusable operating models. I want fewer repeated decisions. I want product prompts that talk about the product, not the same architecture rules again and again.

That is why I made this repo. It is a small place to collect the architecture decisions I already know I am likely to want: Remix, TypeScript, AWS, Cognito, email, Postgres-compatible data, modular styling, realistic tests, and a delivery order that makes the agent think before it writes.

The product can change. The engineering baseline should not have to be rewritten every time.

What I want next

I expect this repo to grow slowly.

I do not want twenty half-baked base prompts. I want a few reliable ones for platform shapes I actually use. The next useful step is probably more examples of app-specific prompts that inherit the Remix 3 AWS baseline without repeating it.

For me, that is the real value: less prompt noise, more architectural consistency, and fewer throwaway first drafts.

AI-assisted delivery should not mean starting from scratch every time. It should mean reusing the engineering judgment I already paid for on the last app.