A website in a day, an app in a fortnight
Both are possible and neither means what the ad says. What genuinely fits in a day, a week and a fortnight, what gets quietly dropped to hit those numbers, and how to buy speed without buying a problem.
Search for this and you will find a lot of people promising it. Most of them are not lying exactly. They are quoting the part of the job that fits and leaving out the part that does not.
I work fast, faster than I did two years ago, and the reason is real: the thing I hand over is a working prototype built with AI coding tools rather than a folder of screens. So I would rather explain honestly what speed does and does not buy you.
A website in a day: yes, with conditions
What genuinely fits: a single-page site for a business that already knows what it does. Hero, what you offer, proof, contact. Real copy, real images, responsive, fast, and properly set up for search.
That last part is worth being specific about, because "with SEO" is where these offers usually go soft. In a day you can absolutely get the foundation right: a title and description written for a search result rather than for your brand deck, headings in a real order, image alt text, a sitemap, structured data that says who you are, and a page that loads quickly on a phone. That is the whole technical layer and it is genuinely a day's work.
What does not fit: ranking. The foundation is a day. Ranking is months of having something worth linking to. Anyone selling "a website in a day, with SEO" and implying traffic is selling you the foundation and letting you hear the outcome.
What quietly gets dropped when someone promises a day: your actual copy, replaced with near-enough words; a template you will recognise on four other sites; and any thinking about who the visitor is and what they need to be convinced of.
If your business is straightforward and you need to exist online this week, a day is a good trade. If what you sell takes explaining, the writing is the project and it is not a day.
An app in a fortnight: depends entirely on which app
What genuinely fits in two weeks: a working, clickable product that does one job end to end, with real data flowing through it, that you can put in front of people and learn from. Not a slideshow. Something that behaves.
I have built exactly this repeatedly. The prototypes on the case studies run in a browser with no install and handle real interaction, real state and real edge cases, and they were built in that kind of timescale. On one project 76 engineering tickets were written against the running prototype, with the rule that if the ticket and the prototype disagreed, the prototype won.
What does not fit: a real app, in the stores, with accounts, payments, notifications, support for the thing going wrong at 2am, and the eleven screens you have not thought of yet. That is months, and the gap between the two is mostly the unglamorous half: what happens when there is no data, when the network drops, when somebody taps the wrong thing twice.
What quietly gets dropped at fifteen days: every empty state, every error, accounts, and anything that requires deciding rather than building.
Why it is faster than it was
The honest mechanism, because it matters for judging any quote you get.
Static screens cannot express behaviour. What happens at 27% zoom, what a second finger does mid-drag, what the ninth overlapping item does. To specify those in pictures you need hundreds of frames, and engineers still guess. Every guess becomes a bug found in testing, which is the most expensive place to find one.
Building the behaviour instead removes that entire round trip. Review becomes ten minutes with a link rather than a meeting where everyone pictures a different product. The questions that used to surface in QA surface in week one while they are still cheap.
What did not get faster: the research, the flows, and the argument for why the design is right. Those take as long as they always did. The longer version is here.
How to buy speed without buying a problem
Ask what is excluded, and get it in writing. Speed is almost entirely a scope decision. A fast quote with no exclusions list is a slow project that has not admitted it yet.
Ask to see something on day one. If a fortnight is real, there is something to look at almost immediately. If the first thing you see is in week two, it is not a fortnight project.
Decide what you are actually buying. Something to learn from, or something to launch? Both are legitimate. They are not the same purchase and they are not the same price, and most disappointment comes from buying one while expecting the other.
Be suspicious of a number quoted before the problem. Anyone who can tell you the timeline before they know what is wrong is quoting a template.
The version I would actually recommend
Spend a few days finding out what the thing needs to be. Then build a narrow version that does one job properly and put it in front of real people.
That is usually faster to something valuable than fifteen days spent building the wrong fifteen days of product.
If you have a date and a thing, send me both. I will tell you plainly what fits inside it, and what I would leave out.