SiteGround Academy

If you’re part of a startup, there has never been a better time to get a first version of your product in front of real people. You no longer need a technical co-founder or a budget for developers. You can build a vibe coding MVP instead: a first working version of your product, created by describing it to an AI tool in plain language rather than writing the code by hand. It exists to test one business assumption with real customers, so you find out whether the idea works before you spend more time on it.

All-in-one tools like Coderick AI have made it fast enough to go from an idea to working software in days, so building is no longer the part that holds you up. This frees you up to focus on everything around it: deciding what your MVP should test, keeping the first version small, reading what early users actually do, and knowing when to bring in a developer.

What a vibe coding MVP is, and what it’s not

A vibe coding minimum viable product (MVP) is the smallest working version of your product that real customers can actually use, built by describing it to an AI tool instead of writing code or hiring a developer. What you get is a web app you can preview privately and publish at its own address, which is why you need an AI web app builder that takes you from idea to something testable in days.

Say you had a cool idea to build a SaaS MVP with AI that solved a real problem for a specific industry. Until a couple of years ago, this meant finding a budget for software development, a technical co-founder, or a year of learning to code, all of which required committing before you had any evidence that people wanted it. Vibe coding removed that step: you can now build the first version yourself, in days, and let real customers tell you whether the idea holds before you spend anything you would miss.

Prototype, MVP, and production product are three different things

These three get used interchangeably, and the confusion can be expensive, because each one answers a different question and takes a different amount of work to build.

• A prototype is something you show your team or a few friends. It can be screens with nothing behind them. It tells you whether the idea makes sense on paper, and nothing more. It’s usually disposable.
• A production product has to work for real clients, keep running when something breaks, handle many people arriving at once, and protect other people’s data. It is built to last, and it costs accordingly.
• An MVP sits between the two. It’s more than a prototype, because a stranger has to be able to use it without you there: someone works through it on their own, with their own data, to do something they genuinely needed to do, and that is how you test your idea. But unlike a prototype, it’s not disposable: if your idea holds up, this is what you keep building on to get to the production product.

What the MVP is for: answering one question, not launching a company

An MVP is a research instrument that happens to look like a product. The question it answers is about user behavior: will people switch from the way they do this now, will they trust software to do the job instead of doing it themselves, will they come back a second time without being reminded, will they pay anything at all.

What makes a question worth building for is that a “no” would change your plans. If you would carry on the same way whatever the answer, you are not really asking anything. And once you have the question, it settles the build: only the features a user has to touch on the way to answering it earn a place. Everything else, however obvious it seems, is a decision you are making before you have the information to make it.

Start with the risky assumption, not the feature list

Before you decide what to build, decide what has to be true for the business to work. Every startup rests on a handful of assumptions, and one of them is load-bearing: if it turns out to be false, nothing else you build matters. That is the one the MVP exists to test.

Naming the one assumption the MVP has to test

Write down everything that has to be true for your idea to work, then look for the one that is both unproven and fatal. Say you want to build a tool that automatically sorts bank transactions into expense categories for freelance bookkeepers. Your idea depends on at least three things:

1. Bookkeepers find manual sorting tedious. Almost certainly true, and you can confirm it in a few conversations without building anything.
2. They would pay a monthly fee for software that helps. Worth testing, but it only matters if the next one is true.
3. They would trust automatic sorting enough to work from it, instead of redoing it by hand. This is the risky one. If bookkeepers check every line anyway, your tool saves nobody any time and the business does not work.

The third assumption decides whether you have a product, and you cannot settle it by asking people. Everyone says they would trust it, right up until they see their own client’s messy data come back with mistakes in it. Assumptions like that can only be tested by letting people use something real, which is exactly what an MVP is for.

Deciding in advance what user behavior counts as evidence

Once you know what you are testing, write down what result would convince you, and do it before anyone touches the product. For the bookkeeping example, that might be: “I will believe bookkeepers trust this if at least half of the people who try it upload a second bank statement within a week, without me asking them to.”

Early results are almost always mixed, and after two weeks of building you will be strongly inclined to read them as good news. A number you committed to in advance is much harder to argue with than a feeling you form afterwards.

How to scope a vibe coding MVP

Scope your MVP to the shortest path a user can take to reach the moment that tests your assumption. Anything sitting off that path can wait. The easiest way to hold that line is to keep two separate lists instead of one.

Build scope and launch scope are two different lists

Build scope is what tests your assumption. Launch scope is the minimum that has to exist before you can responsibly let real people in. They serve different purposes, and merging them into a single to-do list is one of the most common reasons a small MVP can turn into a three-month project. Here’s how to tell the difference between the two:

The launch scope is short, but it is not optional. If you are handling other people’s financial records, a privacy notice and a way to delete data are not polish you add later. In most countries, they are a legal requirement the moment a real customer uses your product.

What to leave out on purpose

The list of things to skip is longer than the list of things to build, and every item on it is something a reasonable person would argue for:

• Accounts for a second type of user. Team access, client logins, admin roles. Build for one person doing one job, and add the rest when you know the job is worth doing.
• Settings and customization. Every option you offer is a guess about what people will want to change, made before you have watched anyone use the product.
• Integrations with other software. Connecting to the accounting tool everyone uses sounds essential and typically takes weeks. It also tests nothing, because nobody refuses a product they like over a missing integration at this stage.
• Billing systems. You can take payment with an invoice or a payment link long before you build subscriptions, and doing it by hand teaches you more about how people buy.

How small startup teams divide the vibe coding work

Building an MVP for non-technical founders roughly splits into six tasks that can be completed by a startup team of two or three people, and only one of these tasks involves the actual vibe coding. Someone has to stay close to customers, someone has to decide what the MVP is testing and what result would count, someone runs the build, the whole team has to try the thing, someone onboards the first users by hand, and someone brings in technical help when the risk calls for it.

If you are on your own, you still own all six. The value of the split is that it stops the build from swallowing the rest, which is the standard failure: the founder disappears into the tool for two weeks, comes back with something impressive, and has not spoken to a customer since. Do the six jobs in sequence, not as one blur, and note that only one of them requires the AI at all.

How to build an MVP with AI using Coderick AI

The build is the most straightforward part of the vibe coding MVP process. You describe the product in plain language, look at what the AI produces, and refine it over a few rounds until it does what you need. (Our guide to the vibe coding workflow walks through that loop in more detail.)

What varies between one AI MVP builder and another is mostly what happens after the MVP gets built. Many tools generate a project and then leave you to work out hosting, databases, and deployment on your own (see our vibe coding glossary to learn all about these), which is where founders building an MVP without coding usually get stuck. With Coderick AI, those pieces are handled inside the platform:

• Hosting is included and optimized: You build safely on a private preview domain, and there is no separate hosting account to set up or pay for.
• The database and user accounts come with it: If your MVP needs to store information or let people sign in, it works without you configuring anything, though you also get full access to a database admin dashboard to manage your data directly if needed
• Publishing is one step: When the product is ready on your private staging environment, you simply click Publish. This automatically copies the current state of your app to your live, public web address (and paid plans fully support custom domains).

Start with one prompt

Your first AI MVP prompt should describe your build scope and say explicitly what to leave out. That second part matters more than people expect: asked simply for “a tool for bookkeepers,” an AI builder will helpfully add an admin dashboard and a settings page you never wanted and now have to maintain. It’s highly recommended to provide clear business requirements and add functionalities step-by-step, rather than dumping 5-6 features into a single prompt. You can even upload an image of a layout you like and ask the AI to use it as design inspiration.

A simple prompt you can start with:

Using this prompt for the bookkeeping example, here’s how it looks:

“Build a web app for freelance bookkeepers that allows them to upload a CSV bank statement and automatically sort transactions into expense categories. Do not build an admin panel or user settings.”

After submitting this prompt, Coderick AI will generate a functional web application tailored for freelance bookkeepers to upload and categorize CSV bank statements, excluding an admin dashboard or user settings as instructed. To support these file uploads and data sorting features, the platform will automatically provision a database under the hood. You will immediately see the results in a split-screen interface, which features a text summary of the AI’s implementation plan on the left and a live, interactive preview of your new application hosted on a private staging domain on the right:

Then iterate

It’s possible that the first AI-built MVP version will get something wrong, and your job is to describe the difference between what you see and what you meant, then run it again. Two or three rounds are normal for a narrowly scoped MVP. For quick visual tweaks, you can use Coderick AI’s “Visual Edit” mode to click directly on an element and apply AI-powered changes in place, saving you from writing lengthy chat prompts.

Remember to treat the AI like a real developer: back-and-forth testing and debugging are natural parts of the software lifecycle. If you find yourself on the twelfth round, it usually means the scope grew while you were working, not that the tool is failing you.

How to test an AI-built MVP with early users

Testing an MVP means picking a small group of people who have the problem, getting them to do a real task with it, and watching what happens. Before you start, decide what the finish line is. Every MVP has one moment where the user gets the thing they came for. In the case of the bookkeeping tool, it is not signing up or uploading a file, it is exporting a corrected list they then actually use with a client. Everything before that moment is setup, and everything you measure is measured against it.

Ten or 15 people is enough, as long as they are the right ten or 15. People who respond because they know you will be kind, and kindness is not data. Go to wherever your users already are and recruit individually.

With that group, three things are worth measuring, and each one answers a different question.

• Do they get there at all? Count how many reach that finish line the first time. If eight of 15 sign up and only three export a file, the problem is in the middle, and you can go and find out exactly where they stopped.
• Do they come back and do it again? For an MVP, coming back means repeating the core action, not logging in. A second bank statement uploaded a week later means the first one was worth their trouble. One to two weeks is a long enough window to tell, and this is usually the strongest signal you can get this early.
• Will they hand over money? This is where most founders fool themselves. Asking “would you pay for this?” tests nothing, because saying yes is free. Testing it means asking for the payment itself, before the product is really ready: an early-access price for the next three months, a paid pilot, a deposit, or, for business customers, a written commitment to buy. The honest version of this bar is a handful of paying customers who are not friends of yours.

Which of the three matters most depends on what you decided to test. If your risky assumption is that people will trust the output, repeat use is your answer and payment can wait. If the assumption is that anyone will pay for this at all, then you need to ask for money in week one, even if the product is held together with tape.

What early behavior tells you, and what it does not

Some signals are worth acting on. Others feel good but mean nothing.

The most useful thing to watch is where people stop. If four of your first ten users upload a file and never look at the results, you have learned something precise and slightly painful, which is exactly the sort of thing an MVP exists to produce. An MVP that produces a clear “no” has done its job as well as one that produces a “yes,” and it has done it for a fraction of what finding out later would have cost.

When you spot these drop-offs or receive specific complaints, you don’t need to start over. You can simply jump back into the Coderick AI chat, describe the necessary workflow changes to the AI, and iterate on your existing app to quickly deploy a better version.

When to bring in a developer for a vibe-coded MVP

Most of the advice you will find on this question is published by companies that sell development services. Their answer to “when do you need a developer” is structurally likely to be “now.” However, a vibe-coded MVP can carry real users for longer than most people admit. What it should not do is carry them past a specific set of lines:

• Complex business and application logic: AI builders are excellent at standard features, but if your app needs to follow highly specific, multi-step rules or complicated math, the AI can get confused. If you find the AI constantly breaking one feature while trying to fix another, a developer can step in to write those specific rules.
• Connecting to outside services (integrations): While many AI tools have built-in connections for popular services (for example, Coderick AI can automatically connect to Stripe to take payments), asking the AI to connect to something like a custom stock market feed is often restricted. A developer is needed to securely set up those custom bridges.
• Outgrowing the built-in database: Some vibe coding tools automatically set up a simple storage system in the background to hold your MVP’s information, like user passwords or a list of items for sale. Coderick AI, for example, gives you a beginner-friendly database that requires zero manual setup. However, if your MVP evolves into a massively popular product and requires a highly customized, heavy-duty data system to handle millions of records, you will eventually need a developer to upgrade it.
• Highly custom designs and animations: AI MVP builders are fantastic for generating clean, modern, and standard website layouts. But if your brand requires deeply interactive visual effects, complex 3D animations, or highly specific custom designs that break standard grid layouts, the AI will likely struggle to get it exactly right. Human developers and designers are still needed for intricate visual work.

Build the smallest vibe coding MVP that can teach you something

Vibe coding has not removed the discipline that startups have always needed. It has removed enough of the build friction that a small team can get to a real answer sooner, which is a different and better thing than shipping sooner. The founders who get value out of vibe coding are the ones who decided what they were testing before they decided what they were building.

So start from the question. Name the assumption that would sink you if it were wrong, work out what behavior would settle it, build only the path that gets someone to that moment, and put it in front of 15 real people. Whether the answer is yes or no, you will have it in weeks and will have spent almost nothing to get it. That is the case for a vibe coding MVP, and it holds whether you build a SaaS MVP with AI, an internal tool, or something nobody has a name for yet.

[96]

FAQs

Claude Opus 5 is Anthropic’s most recent Opus-tier model for complex work: long documents, detailed research, multi-step projects, and coding. It costs $5 per million input tokens and $25 per million output tokens, exactly what Opus 4.8 cost. It can hold 1 million tokens in a single conversation, and it sits below Claude Fable 5, Anthropic’s most powerful model, at half of its price.

Anthropic released Claude Opus 5 on July 24, 2026, and most of the coverage since has been benchmark scores and per-token rates. But if you run a small business rather than an engineering team, is it worth it for your daily workflow, and is it going to cost you more? This guide will tackle these questions, including how you can compare Claude Opus 5 to other leading models like Google’s Gemini 3.1 Pro and OpenAI’s ChatGPT 5.6 in SiteGround AI Studio, all under a single subscription.

Claude Opus 5 vs Opus 4.8: what actually changed

Three things changed in Claude Opus 5 vs Opus 4.8, and the price was not one of them.

1. It thinks before it answers. Opus 5 now works through a problem before responding, instead of doing that only when you ask it to.
2. It holds far more at once. In paid Claude chat, Opus 5 expands the context window from Opus 4.8’s 500,000 to 1 million tokens (the small chunks of text that AI use is measured and billed in, each one roughly three-quarters of a word), so it can work across a large set of documents without you breaking them up.
3. It knows more recent things. Its knowledge runs to May 2026, the most recent of any Claude model. That date is the knowledge cutoff, the point where the information it was trained on stops.

The rates stayed exactly where Opus 4.8 left them, which is the actual story of this release. Anthropic held the price of its mid-tier model steady while closing most of the gap to its flagship, so work that was only worth running on a cheaper model last month may be worth running on this one now.

Claude Opus 5 pricing: the same rates, but different real-world costs

Before the numbers, it helps to know which of them apply to you, because there are three quite different ways to pay for Claude.

• If you use the Claude chat app, you pay a flat monthly fee. Free gives you Sonnet 5 with daily limits. Pro is $20 a month (about $17 if you pay yearly) and gives you the full model menu including Opus 5, though Sonnet 5 stays the default until you change it. Max is $100 or $200 a month and makes Opus 5 the default. Choosing Opus 5 instead of Sonnet 5 on any of these plans costs you nothing extra. What it costs is headroom: usage limits run on rolling five-hour sessions with weekly caps on top, and a heavier model works through that allowance faster. Run out, and you can switch on usage credits, which bill at the per-token rates below.
• If you use a bundled AI workspace, you pay a flat plan fee and your usage is measured as an allowance. For example, SiteGround AI Studio works this way, with a monthly token allowance rather than a per-message limit. Here your model choice does show up, because heavier work draws down the allowance faster.
• If you use the API, you pay per token, the way you pay for electricity. You would only be here if you or someone you hired built something that talks to Claude directly, like a chatbot answering questions on your website or a tool that reads your emails. At the end of the month, you get a bill based on how much text went in and out.

The table below is that third route, the API rate card. You pay one rate for what you send the model, called the input, and a higher rate for what it sends back, the output, and as a rough guide 1,000 tokens is about 750 words. Even if you never touch the API, these rates are the way to see what different kinds of work weigh.

Opus 5 matches Opus 4.8 to the cent and undercuts Fable 5 by half. That is a real saving on paper, but it’s not a guarantee that your next invoice will look the same, for a reason most launch coverage files under specifications rather than costs.

Thinking is on by default now, and that is what moves your Claude Opus 5 bill

Opus 5 reasons through a request before it responds, and it now does this by default rather than only when you switch it on. That working out happens in the background, but it’s made of text like everything else, so it’s counted in tokens (these are usually called thinking tokens) and billed at the higher output rate. The same request that cost you a certain amount on Opus 4.8 can therefore cost more on Opus 5 at identical published prices, because the model is doing more work before it speaks.

This is not a hidden fee, it’s the reason the answers are better. It’s also the one thing to understand before you switch, because it explains an outcome that otherwise makes no sense: a model priced identically to its predecessor producing a larger bill.

What the Claude Opus 5 context window means in practice

A context window is how much text a model can hold in mind at one time, counting everything you have sent it and everything it has said back. The Claude Opus 5 context window is 1 million tokens, roughly 750,000 words, or a stack of documents a couple of thousand pages deep. It is both the default and the maximum, with no smaller version to choose from. You can hand it a whole contract set, a year of customer emails, or every page on your website and ask questions across all of it without breaking the material up.

The catch is that a big window is an option, not an instruction. Everything you put into it is input you pay for, so pasting your entire document library into every request is how a task that should cost pennies starts costing real money.

How much does Claude Opus 5 cost a small business?

Less than you would expect for ordinary writing work, and more than you would expect once you start feeding it long documents. The useful way to think about Claude Opus 5 cost is per month of real work, not per million tokens. The examples below are estimates at published API rates, worked out using the rule that 1,000 tokens is about 750 words, and assuming the model’s thinking roughly doubles the output you pay for.

Read them two ways. If you pay per token, this is roughly your bill. If you use Claude through a flat subscription, this is not your bill, since you already paid your $20, but it’s a fair picture of how much of your monthly allowance a given workload eats. Either way, the point is the same: it shows you which of your work is light and which is heavy.

Claude Opus 5 cost examples for content, products, and email

Run all three in the same month, and you are still under $5. But if you ask Opus 5 to read a 300-page report (about 200,000 tokens), that single request will cost a dollar in input before it writes a word. Do that twenty times in a month while you dig through a document set, and you have spent $20, which is more than everything in the table above combined, several times over.

So writing is cheap, and reading is what costs you. On a per-token bill, that’s money. On a subscription, it’s the reason you can spend all morning writing and hit no limits, then upload three long PDFs after lunch and find yourself capped. Either way, the number to watch is how much you are putting in, not how much comes back.

What changes the real cost of Claude Opus 5: caching, batching, and thinking tokens

Three things sit between the published rate and what you actually pay.

• Thinking tokens push it up. As mentioned above, the model’s working out is billed at the output rate, so a request costs more than the visible answer suggests.
• Prompt caching pulls it down, by up to 90%. This is a discount on material you send again and again, such as a style guide or a product list. On Opus 5, anything over 512 tokens qualifies, so even a short brief counts.
• Batch processing halves both rates. The trade is speed: you send work off to be answered within about a day rather than straight away.

If you reach Claude through a subscription or a bundled workspace rather than the API, you will never touch these settings. They are still worth knowing about, because they are why a monthly token allowance stretches further than the raw arithmetic suggests.

What is Claude Opus 5 best for?

Claude Opus 5 is best for work that is long, layered, or expensive to get wrong. The Claude Opus 5 benchmarks worth paying attention to are the ones about sustained, multi-step tasks, because that is where the gap over Opus 4.8 is widest.

Benchmarks are standardized tests that model makers run to compare one model against another. On one of them, FrontierBench v0.1, which measures how well a model handles long jobs made of many steps, Opus 5 scored 43.3% against 18.7% for Opus 4.8. Those are Anthropic’s own evaluations on tasks it chose, so treat them as a direction rather than a promise, but the direction is this: the further a job runs, the more the difference shows.

Long documents and multi-step work

Translated into work you actually have, that means jobs like these:

• Reading something long and telling you what matters. A research report, a set of contracts, a competitor’s whole website: hand over the lot and ask what you should take from it, and it can work across every page rather than the first few.
• Making sense of a pile of feedback. Hand it a year of reviews, survey responses, or support emails and ask what customers keep complaining about, and it works across the whole set rather than a sample.
• Cleaning up messy source material. Turning three inconsistent supplier spreadsheets into one usable catalog is the kind of long, fiddly job where cheaper models start well and drift.
• Projects with several stages. Auditing your existing content, deciding what to keep, and building a plan from it, without you restating the goal at every step.
• Anything involving code. Building, reviewing, or debugging something on your site or in a small internal tool. Debugging means finding and fixing the errors that stop code working, and it is a job where the model has to hold the whole picture to be any use.

We tested it with a long document: we uploaded SiteGround’s 2026 report on AI in WordPress for small businesses in SiteGround AI Studio (where you can pick the leading models from providers such as Anthropic, OpenAI and Google under one subscription), we picked Opus 5 from the model list, and asked this:

“This is SiteGround’s 2026 report on how small businesses use AI in WordPress. I run a small business with a WordPress site and about five hours a week to spend on it. Read the whole thing and tell me the three findings that matter most for someone in my position, what each one actually means in practice, and which one I should act on first.”

Opus 5 pulled figures from across the whole document rather than the opening pages, and built them into a single argument, at one point quoting a line from one of SiteGround’s product managers buried in section four and calling it the most useful sentence in the report. Asked which finding to act on first, it picked one, laid out a two-week sequence, and explained why it had not chosen the more obvious alternative.

Where a cheaper model does the same job

Plenty of the work you do every day does not require Claude Opus 5. Short marketing copy, routine customer replies, summarizing a meeting note, tagging and sorting, first drafts of the kind of thing you write every week: Sonnet 5 finishes all of that to a standard you will not be able to fault. If you cannot tell which model wrote it, you spent more than you needed to, whether that was money on a per-token bill or the session allowance you have left for the rest of the day. Reserve Opus 5 for the jobs where you can tell.

Claude Opus 5 vs Sonnet 5 vs Fable 5: which one fits your business?

Claude is a family rather than a single product, and the practical skill is matching the tier to the task. Here is where each one earns its place.

On Claude Opus 5 vs Sonnet 5, the answer for most small businesses is that Sonnet 5 stays your daily driver and Opus 5 is what you switch to when the work gets hard. Sonnet 5 costs $2 and $10 per million tokens right now, rising to $3 and $15 in September, against Opus 5’s $5 and $25. If you are on the chat app, that gap is not money, since both models are included in the same subscription, and it shows up instead as how quickly you burn through your usage limits. Either way, across everyday writing, you will not see a difference in the output that justifies reaching for the heavier model.

On Claude Opus 5 vs Fable 5, the picture is more interesting than the positioning suggests. Anthropic places Fable 5 above Opus 5 in maximum capability and charges twice as much for it, $10 and $50, yet on several of its own published tests, including FrontierBench, Opus 5 scored higher. For small business work, the price gap is easier to feel than the capability gap. Fable 5 makes sense when you want to hand over a genuinely large job and leave it running unsupervised; short of that, Opus 5 is the sensible ceiling.

And if the question you are really asking is which company’s AI to use rather than which Claude tier, our guide to ChatGPT vs Claude vs Gemini covers that comparison.

Should you upgrade to Claude Opus 5?

• If you mostly write short marketing copy: Sonnet 5 handles this, and paying Opus rates for a social caption is spending with nothing to show for it.
• If you work with long documents, research, or analysis: Yes, and this is the release that makes it affordable. Work you were breaking into chunks to keep costs down can now run in one pass.
• If you build or look after a website or an app: Yes. Coding and debugging are where the gains over Opus 4.8 are clearest, and holding a whole project in context is the difference between help and noise.
• If you are paying for several AI subscriptions: Then Opus 5 is not really your question. Consolidating what you already pay for is, and it will save you more than any model choice.

The bottom line: is Claude Opus 5 worth it for your business?

For most small businesses, the sensible setup after this release is the same shape as before, with better economics: a cheaper model for the daily grind, and Claude Opus 5 for work that is long, messy, or consequential. What changed is that reaching for the better model no longer costs a premium, so whether Claude Opus 5 is worth it depends less on the model than on what you point it at.

And don’t take anyone’s word for it, including ours. The most useful Claude Opus 5 review is the one you run yourself. Take one real job you already do, run it on the model you use now and on Opus 5, and compare the finished result and what each run cost. Two tasks in, you will know which of your work belongs on which model, which beats any benchmark chart.

Claude Opus 5 is available in SiteGround AI Studio, where you can compare it to other leading models like Google’s Gemini and OpenAI’s ChatGPT, all under a single subscription. Instead of juggling multiple paid accounts for different providers, AI Studio gives you access to all these major models in one intuitive workspace. When you open a new chat, you can easily switch to Claude Opus 5—or any other available model—using a simple dropdown menu right in the interface. This makes it incredibly easy to run your own real-world comparison: just type your prompt, test it on your usual model, and then select Opus 5 from the dropdown to instantly compare the results.

[97]

FAQs