Websites, internal tools, and apps — picking the right project type

Website and Landing Page project types produce real public-facing marketing sections — the kind of copy a visitor reads to decide whether to buy or call. Internal Tool, Admin System, Client Portal, and App project types instead produce real operational screens: actual views inside working software, with real field names, table columns, statuses, and buttons, described the way a genuine product spec would describe them — never a tagline, never a "Get a Quote" button, never persuasive language, because there's no customer reading it.

This distinction exists on purpose because of a real, confirmed failure: an owner once asked for an internal dispatch tool and got back a customer-facing brochure with dispatch-flavored words sprinkled into marketing copy instead of an actual tool spec. Picking the right project type is what keeps that from happening to your project.

A strong internal-tool description names the actual workflow, not the feeling you want a page to give someone. Compare a vague ask ("we need a dashboard for our team") to a real one: a residential HVAC company describing a four-person crew, needing to see customer name, address, crew assigned, and a status that actually reflects their process (Quoted / Scheduled / En Route / On Site / Done / Invoiced) — with something as specific as a badge counting jobs still unassigned by 7am. That's the level of concrete detail that turns into a real screen instead of a generic "key metrics" dashboard, which is the default failure mode when there's nothing specific to work from.

If your project genuinely needs a customer-facing side and real software behind it — a landscaping business with both a marketing site and a crew dispatch view, say — you can select both. aiKit is instructed to write both a real set of marketing sections and a real set of operational screens for two genuinely different audiences (your customers vs. your own team), and to keep them reading as different material, not the same content relabeled. When you do this, make it clear in your description which parts are for the public and which are for staff — that's the detail that keeps the split honest.

If none of the listed types fit and you pick "Something Else," aiKit infers from your description alone whether it reads as public-facing, operational, or both. If the description is too thin to tell, it defaults to a minimal, honest overview rather than guessing a pitch. In other words, skipping the type selector doesn't mean you can describe less — it means the description alone now has to carry the signal a type selection would otherwise have given it for free.