Customizing Templates: Adding a Field and Adding a Page

After using a bought template for a while, you'll want to add things sooner or later: a “birthday” field on the customer table, a “services” page for the booking system. Before adding anything, establish one principle — fields are defined in one central place; adding a field means changing the definition, not just the words on a page. If you only change page copy, the new data can't be saved — which is the same as not adding it.

One principle: changing only page copy doesn't count as adding a field

Fields in a template (customer names and phones, appointment times on the booking table) are all defined centrally somewhere; forms, lists, and detail pages all render from that definition. So the correct way to add a field is: add it in the definition, and the three pages change together automatically. The input box you see on the page is just the definition's shadow — changing the shadow does nothing.

Step 1: Have the AI find where field definitions live

Each template's definition lives in a different place — don't dig around yourself. Just ask:

In this project, which file defines the customer form fields? Just find it and tell me, don't change anything yet.

Once it points them out, glance at the filenames and structure, and only then let it act. This is the previous post's method in action.

Adding a field in three steps

• ·Add the field in the definition: state the type (text, number, date, image) clearly, whether it's required, and whether there's a default
• ·Have the AI run the type check and tests to confirm nothing else broke
• ·Walk through the page yourself: create a record, fill in the new field, save, reopen and check it's still there. Data that saves is what counts as done

Adding a new page: first think through where it's reached from

Adding a page takes one extra thought over adding a field: how do users get to this page? A new nav entry, or jumping from some detail page? Decide the entry point before having the AI write the page, or you get an island page — it exists but users can never reach it. The page itself is also added through the template's page config, the same “definition” route as fields.

Two things you must do after changing

• ·Run the type check (npm run typecheck) and tests (npm test) — zero errors is the bar
• ·Click through the affected flows completely: create, edit, delete — don't just look at whether the page looks right

Field type selection: a wrong choice is worse than not adding

The first step of adding a field isn't naming it — it's picking the type, and a wrong pick is painful to fix later. Text is the most general, but don't use text for everything: pure numbers like prices and quantities get numeric types, or “sort by price” will sort wrong later; dates and times get date types — dates stored as text can't be filtered by time; images get image types, which usually store a file address — don't convert images to base64 and stuff them into text fields, the database will explode.

There's also a “relation” type: e.g. an order linking to a customer — don't store the customer's name text, store the customer's ID as the relation. Names change, IDs don't. Store the name as text and the day the customer renames themselves, all historical orders break. Anything “picked” — customers, categories, service items — prefers relations. That's the single most valuable lesson in database design.

Required and defaults: the fewer required, the better

Every required field is a gate; one more gate means more people abandoning the form halfway. So require only what's truly indispensable: names, contact info, that kind of thing. Everything else gets a sensible default — “status” defaults to “pending”; fields without a default are allowed empty and filled in later. Shorter forms complete better — measured, not guessed.

One more pit: what about old data when you add a required field? The database already has a thousand customer records; the new “birthday” is required, old records have no birthday, and saving throws an error. Two ways to handle it: fill a default into the old data, or allow the field to be empty. Before acting, ask the AI: “How many rows are in this table now? Will adding a required field affect them?” Have it check first — don't just go in.

Deleting a field: back up before touching anything

Deleting a field is more dangerous than adding one, because deleted data doesn't come back. Three steps before acting: first have the AI search the whole project for where the field is used — lists, details, search, exports, statistics can all reference it; once it's confirmed unused, export the data and keep a copy in case you delete wrong; then delete the definition and all references, run the type check and tests — all green is what counts.

Don't celebrate after deleting — click through the affected flows on the page: create, edit, list display, confirming there's no undefined or error. Deleted-field bugs love hiding in rarely used features like exports and statistics; give them a click and save your users from finding them first.

Renaming a field: looks trivial, is dangerous

Renaming “customer name” to “contact person” sounds like changing two words, but it's changing the definition, every page that references it, the database column name, and the export templates — miss one and it errors. Before renaming, have the AI search the whole project for the field name and list every reference; run the tests after changing. Once a field name is set, don't rename it unless you must — renaming always costs more than you think.

Too many fields making the page long: group them

With a dozen fields the form won't fit one screen and users hate it. The fix is grouping: basic info in one group, contact info in another, advanced options collapsed. Grouping is also configured in the definition, not hard-laid-out on the page. Remember: users fill one group at a time, then expand the next — completion rates beat one long strip by a lot.

The add-field prompt template for the AI

Copy this and fill in your field: “In the customer table's field definition, add a field: birthday, type date, nullable, not required. Change the definition only, don't touch other fields. Run the type check and tests when done, then tell me whether the form, list, and detail pages all picked it up automatically.” Say the type, required-ness, and default in one go — the AI won't need to ask back and forth, saving money and hassle.

Dropdown options: where do the option values live

For dropdowns like “order status,” where do the values live? Two approaches: hardcoded in code, or stored in the database. Options that basically never change (like gender) are simplest hardcoded; options that change often (services, pricing plans) belong in the database as configurable data — otherwise every new option means editing code and redeploying. The test: will this option change in the future? If yes, put it in the database — don't be lazy.

Image fields: where to store them

Don't store images in the database; the database only stores the image's path or address. Image files go in the server's uploads directory or object storage. When backing up, remember to include the image directory — many people back up only the database, and when the server dies all images are gone, leaving a pile of dead paths in the database. Use relative paths, not hardcoded domains, so switching domains doesn't require bulk data edits.

Money: store “cents,” not “dollars”

Fields for prices and amounts store “cents” (integers), never “dollars” (decimals). Computers have floating-point precision problems — 0.1 + 0.2 ≠ 0.3 — and that bug hides deep. Store integer cents and divide by 100 when displaying dollars. That's the iron rule of every money-touching system; build the habit early and save yourself rework later.

Adding pages: the list, detail, form trio

A new feature usually adds three pages together: a list page (see all), a detail page (see one), a form page (create and edit). Before acting, think through the entry: from the nav, or jumping from some detail page? Decide before having the AI write, or you get an island page — it exists but users can never reach it. And don't skip permissions: can this page be viewed without login? Only by yourself or by everyone? Fixing permissions after launch is more trouble than adding the page itself.

Too many pages: how to organize navigation

With a dozen pages the nav bar overflows. The fix: group related ones together; tuck rarely used ones into a secondary menu; add breadcrumbs so users know where they are. The rule: users reach any page within three clicks — beyond three is a maze. Navigation is the site's skeleton; with a broken skeleton, adding more pages is useless.

Search box: to add or not

Once you have hundreds of records, add a search box. Start with the simplest search: fuzzy match by name — it lasts a long time. Don't start with full-text or pinyin search; those are for when you have tens of thousands of records. Put the search box in the most visible spot on the list page, not in a corner. When users can't find something, their first thought is “this site is bad,” not “let me look harder.”