01 · Brochure · leans WordPress
Calling card
A calling card is a home, about, services, work or proof, and a way to reach you. Maybe a FAQ. It is not a blog, not a store, not a login. People land, understand, and write. Most “we need a website” jobs are this — and most agencies upsell them into something noisier.
You know it is this if: You can list the pages on one napkin. Nobody logs in. You update a few times a year, not every morning.
On WordPress
WordPress is the default. You (or a staff person) edit pages in a real editor. I build a custom theme so it is not a template with your logo stuck on. Contact form, schema, sensible SEO, hosting — done.
On Laravel
Laravel is the long way around for a calling card unless the rest of the job is a custom app and this is just the public face. If the brochure is the whole job, do not pay for a custom CMS.
Usually includes: Custom design · 5–8 pages · Contact form · Basic SEO · Mobile layout
Watch: If you also need client logins, quoting, or a catalog with rules, this is the wrong kind — pick portal, store, or custom app.
Stamp this on a ticket
02 · Brochure + journal · leans WordPress
Shop window
Same bones as a calling card, plus posts. Not a magazine with a staff. A contractor posting job photos. A clinic explaining procedures. A shop announcing drops. The journal is marketing you own, not a rented social feed.
You know it is this if: You (or someone on staff) will publish at least monthly. Categories and a search box matter. Pages stay, posts accumulate.
On WordPress
This is what WordPress was born for. Custom theme, a post index that does not look like 2012, categories you actually use, RSS if you want it, Open Graph so shares do not look broken.
On Laravel
Only if posts are a side effect of some other system (jobs, inventory, case files) and the “article” is generated from data. If humans are writing essays, WordPress.
Usually includes: Calling-card pages · Post index + single · Categories · Share cards · Author byline if needed
Watch: A blog you will not write is a liability. If the cadence is imaginary, stay a calling card.
Stamp this on a ticket
03 · Editorial · leans WordPress
Magazine
Editorial is a different machine from a brochure with posts. You have sections, maybe issues, maybe paywalled pieces later, authors with bios, related reading, and a home that has to re-layout as stories land. The CMS is the product.
You know it is this if: More than one person writes. Editors exist. Taxonomy is a fight you want to win up front (sections, tags, series).
On WordPress
WordPress with a custom editorial theme, user roles (author / editor / admin), maybe a homepage you compose. Co-Authors, featured stories, newsletter hook. Gutenberg or a tighter editor — your call, I will not force a page-builder.
On Laravel
If the magazine is really a database of records (stat sheets, archives with brutal filters, a membership that is the business), Laravel can be cleaner. If the work is writing and laying out stories, WordPress.
Usually includes: Sectioned home · Author pages · Roles · Related stories · Search
Watch: Do not start here if you have one writer and a hope. That is a shop window.
Stamp this on a ticket
04 · Work on the wall · either machine
Portfolio
A portfolio is a gallery with an argument. Each piece has a problem, a constraint, a result. Filters by type if the body of work is large. Contact is the point. Photographers, shops, architects, me — same job, different materials.
You know it is this if: You can name 8–30 pieces worth showing. Each one can stand as a short story, not just a JPEG.
On WordPress
Custom post type for work, a theme that treats images as first-class, light taxonomy. Easy for you to add a job without me.
On Laravel
If case studies pull from a live system (projects, invoices, before/after from a field app), Laravel. If you are uploading finished stories, WordPress is simpler.
Usually includes: Work index · Case study template · Filters · Contact
Watch: A mosaic of every file on the disk is not a portfolio. Edit.
Stamp this on a ticket
05 · Hours, menu, visit · leans WordPress
Venue / restaurant
Hospitality sites fail on stale hours and PDFs nobody can pinch-zoom. The job is: tonight’s hours, the real menu, how to get there, whether you take reservations, and a way to book a party without a phone tree.
You know it is this if: The menu or hours change. Staff will be asked to update it. People arrive from Maps, not from your brand campaign.
On WordPress
WordPress with structured menu items (not a photo of a chalkboard as the only menu), schema for local business, events, maybe OpenTable / Resy embed or a simple request form. I will not trap the menu in a slide carousel.
On Laravel
If you run multiple locations with different menus, inventory-tied specials, or a real reservation engine you own, Laravel. One restaurant with a seasonal menu: WordPress.
Usually includes: Menu as content · Hours · Map + schema · Events · Private-dining form
Watch: If the real need is a full booking engine with deposits and staff, that is bookable service, not a venue brochure.
Stamp this on a ticket
06 · Appointments · either machine
Bookable service
Consultants, clinics, tutors, salons, inspectors. The hard parts are availability, buffers, time zones, cancellations, deposits, and who is allowed to book what. A pretty page with an embed is not the same as a system you own.
You know it is this if: The calendar is the business. No-shows cost money. You have rules (“new clients 90 minutes”, “not Sundays”) that a generic widget keeps getting wrong.
On WordPress
If the rules are close to what a serious booking plugin already does, WordPress plus that plugin, themed so it does not look bolted on. Faster. You live with the plugin’s ceiling.
On Laravel
If the rules are yours (crew dispatch, multi-step intake, equipment, travel time, wholesale vs retail slots), I build the calendar in Laravel. You own the logic. This is the better long-term machine when booking is the product.
Usually includes: Service list · Availability · Confirmations · Cancel / reschedule · Staff or resource rules
Watch: Payments on bookings, SMS reminders, and staff roles add real weight. Name them as add-ons so the ticket is honest.
Stamp this on a ticket
07 · Paywall / community · either machine
Membership
Membership is not a plugin checkbox. It is identity (who is in), entitlement (what they get), billing (what they pay), and the day someone is angry about a charge. Content clubs, coaching cohorts, private libraries, association directories.
You know it is this if: You can name the plans and what each one unlocks. You will have failed payments, comps, and a person who forwards their login.
On WordPress
MemberPress / similar on WordPress is fine for “pay to read / watch / download” with a few levels. I will still custom-theme it. Do not expect a unique product inside the member area — that is an app.
On Laravel
If members log in to *do* something (dashboards, file exchange, quoting, chapter tools), Laravel. Billing via Stripe. Roles you can actually reason about. This is where WordPress membership plugins start lying.
Usually includes: Accounts · Plans · Gated content or tools · Billing hooks · Admin of members
Watch: Community features (feed, DMs, groups) are a different, heavier product. Say so if you want them.
Stamp this on a ticket
08 · Catalog + cart · leans WordPress
Store
A store is products, variants, cart, checkout, orders, email receipts. Simple until it is not: wholesale price lists, bundles, subscriptions, made-to-order, inventory in a warehouse that is not WooCommerce.
You know it is this if: You can sketch the catalog. Checkout is card or Square/Stripe. Shipping is a real carrier or local pickup — not a novel.
On WordPress
WooCommerce on a custom theme is the default for a standard catalog. I will not install 40 helper plugins. Tax, shipping, product types I name up front.
On Laravel
If pricing is a formula, catalogs are per-customer, or checkout is a quote not a cart, Laravel. Also if the “store” is a side door on a larger system (portal + buy). Do not custom-build a generic T-shirt shop.
Usually includes: Catalog · Cart · Checkout · Order email · Admin of products
Watch: Marketplaces (many sellers) and wholesale portals are not stores. Different kinds.
Stamp this on a ticket
09 · Many sellers · leans Laravel
Marketplace
Two-sided systems are custom work. Onboarding sellers, payouts, dispute paths, search that does not suck, fees. WordPress “multi-vendor” plugins exist and they are how you inherit someone else’s mess.
You know it is this if: You can describe both sides and how money moves. You are prepared for this to be a product, not a brochure.
On WordPress
I will talk you out of Woo + a vendor plugin unless the volume is tiny and the rules are boring. Even then, read the plugin’s support forum first.
On Laravel
Laravel. Stripe Connect or equivalent for payouts. Real roles. This is an application with a marketing site around it.
Usually includes: Buyer + seller accounts · Listings · Search · Orders / payouts · Admin moderation
Watch: Budget and time sit in the “forge” band. A calling-card-sized budget cannot buy this.
Stamp this on a ticket
10 · Find a thing · either machine
Directory
Directories look like websites and behave like databases. Facets (city, specialty, price, open now), claimed listings, maybe paid placement. The design job is making a dense result feel calm. The engineering job is not painting yourself into a plugin’s custom-field corner.
You know it is this if: You can name the listing type and the five filters people will actually use. “And a map” is not a strategy by itself.
On WordPress
A few hundred listings with simple fields: WordPress + a custom type can work. I still want a real search, not a plugin that dumps 40 checkboxes.
On Laravel
Thousands of listings, geo, “open now”, paid tiers, claimed profiles, or import from another system: Laravel. Search is a first-class piece, not a widget.
Usually includes: Listing model · Filters · Listing page · Claim or submit · Admin
Watch: If listings are properties with IDX, that is real estate, which has its own pipes.
Stamp this on a ticket
11 · Login, files, jobs · leans Laravel
Client portal
A portal replaces the “I emailed the PDF” business. Roles, audit trail, the thing that happened last Tuesday is still there. This is the job I do most often for operators who outgrew Drive + Calendly + a spreadsheet.
You know it is this if: You can name the objects (jobs, properties, animals, claims, trips) and who is allowed to see which. Email is currently the database.
On WordPress
WordPress can fake a portal with membership + a file plugin. It gets brittle the moment the object is not “a page.” I will say no if the portal *is* the business.
On Laravel
Laravel. Auth, roles, the actual objects, notifications, an admin you can stand. This is why the stack exists.
Usually includes: Accounts + roles · The core objects · File exchange · Status · Activity log
Watch: Tell me what it replaces. “A portal” with no objects is a mood, not a spec.
Stamp this on a ticket
12 · Courses · either machine
Learning
LMS is a trap word. Some people need “video in order, quiz at the end, certificate.” Some need cohorts, assignments, grading, drip, community. Those are different weights.
You know it is this if: You can outline one course as a table of contents. You know if progress matters or if it is just a library.
On WordPress
A library of lessons with a paywall: WordPress LMS plugin, themed, no extra social layer. Fine.
On Laravel
Cohorts, assignments, custom progress rules, corporate seats, or the course sitting on top of another product: Laravel.
Usually includes: Course structure · Player or lesson template · Progress · Gating
Watch: Live Zoom plus a Google Drive is not an LMS. Do not commission one until the teaching is real.
Stamp this on a ticket
13 · Sermons, give, gather · leans WordPress
Church / nonprofit
The editor will not be a developer. The homepage has to survive a volunteer with a JPEG. Sermons need audio/video that does not autoplay on cellular. Giving should be a provider you already trust (not a novel processor I invent).
You know it is this if: A staff member or volunteer will update events and sermons. Giving already happens somewhere.
On WordPress
WordPress. Custom theme with very boring, very clear admin. Sermon post type. Events. Embedded giving. I will train the volunteer path so I am not the bottleneck.
On Laravel
Only if this is actually a member portal, a school, or a multi-campus system with real data. The public church site is WordPress.
Usually includes: Sermon archive · Events · Staff · Give (embed) · Contact
Watch: A brand-new giving processor is a finance decision, not a web one. Bring the one you use.
Stamp this on a ticket
14 · Listings · either machine
Real estate
Agent and brokerage sites live or die on listing freshness. If you are on MLS, IDX is a vendor constraint I design around, not a plugin I “just add.” If you are a developer selling your own units, it is a catalog you own.
You know it is this if: You either syndicate from MLS or you own the inventory. Those are different builds.
On WordPress
IDX on WordPress is the common brokerage path. I pick a vendor that does not wreck the theme, and I design the rest of the site so it does not look like every other agent.
On Laravel
You own the inventory (new construction, rentals you manage, land) or you need a portal for buyers/sellers: Laravel, maybe with a WordPress marketing wrapper.
Usually includes: Listing search · Listing page · Inquiry · Agent bios
Watch: IDX contracts and feed delays are not a design problem. Get the vendor named before I quote.
Stamp this on a ticket
15 · Your software · leans Laravel
Custom application
If you are replacing a spreadsheet empire, a desktop tool, or three SaaS seats that do not talk, you want an application. Pages are the skin. The objects and the rules are the work. I have been doing this since before the CMS wars. This is the job.
You know it is this if: You can walk me through a real day in the business and point at the pain. There is a process, not just a vibe.
On WordPress
WordPress is the wrong machine. I will say so.
On Laravel
Laravel (or the smallest honest stack). Auth, the model, the admin, the public pieces that need to exist. I name v1 by what it replaces, not by a feature catalog from a dream.
Usually includes: Discovery on the ticket · The objects · Roles · A v1 you can run
Watch: If you cannot describe the process, start with a calling card and a conversation in writing. Do not commission an app from a mood board.
Stamp this on a ticket