React
Pricing tables in 10 minutes: React component or from scratch?
A pricing table is not a price grid, it is a decision. Here is when to install a component, when to build one from scratch, and what most tables forget.
Key points
- Define the decision first, then draw the columns.
- A ready-made component works if it covers the free plan, the featured plan and mobile states.
- Do not forget loading, error and renewal: those are the states where a pricing table loses money.
A pricing table is a decision page. The visitor is not reading a price list: they are working out which plan is theirs, what they risk and what happens next. If the table does not answer those three questions, the number of columns does not matter.
You can start from a component in the catalogue or write it from scratch. The right choice depends on how many variables you carry: plans, currencies, taxes, trials, upgrades, downgrades, team seats.
The decision first, then the grid
- Which plan do you want to sell? Make it stand out, but do not hide the others.
- Is the price monthly, annual or both? Show the saving without layout shift.
- What does the plan include? One line per benefit, not a wall of ticks.
- What happens after the click? Trial, checkout, contact: the CTA has to say which.
- Who pays? An individual, a team, a company: the copy changes.
Ready-made component or table from scratch
| Case | Ready component | From scratch |
|---|---|---|
| 3 plans, one currency | Yes, in 10 minutes | Only with a very specific design |
| Team seats and invoicing | Yes, if the component handles quantity | You usually need your own API |
| Trial and in-app upgrade | Yes, if you wire the state to the backend | Yes, but the cost sits in the flow, not the table |
| Prices that change by country | Yes, if the price comes from the server | Yes, with more testing |
The three states almost everyone forgets
Loading: the table must not jump when the prices arrive. Error: if checkout does not respond, the button must say what to do next. Renewal: the user must know when the charge lands and how to cancel. A pricing table that ignores these three states is a mockup.
A readable React base
If you take the component, open its page and check that the featured plan is data, not a hard-coded colour. If you build from scratch, keep the plans in an array and render them with a map: adding a plan must not mean copying three blocks of JSX.
const plans = [
{ id: "free", name: "Free", price: 0, featured: false },
{ id: "pro", name: "Pro", price: 24, featured: true },
{ id: "team", name: "Team", price: 79, featured: false },
];
export function Pricing({ plans }) {
return (
{plans.map((plan) => (
{plan.name}
{plan.price} € / mese
))}
);
}
For the full patterns (centred plan, monthly/annual toggle, FAQ and closing CTA), read the Pricing table designs and Monthly/annual billing toggles guides.
Frequently asked questions
How long does a pricing table take?
With a ready-made component, 10–20 minutes. From scratch, half a day once you add the states, mobile and the checkout wiring.
Three plans or four?
Three plans are easier to compare. A fourth only earns its place if it serves a real segment, not if it exists to make the middle plan look cheap.
Where does the monthly/annual toggle go?
Above the columns, with the saving visible, and without changing the table height when the period changes.
Should the price come from the server?
Yes, if it varies by country, currency or promotion. Never duplicate prices in the client: the server is the source.
Can I ship a catalogue component in a commercial project?
Check the licence shown on the record. EneUI reports the licence declared upstream; if it is unclear, ask before you ship.