Two days to put a website online is a normal thing to try now. The stack is a template. An agent writes the pages faster than you can read them.
What you have at the end of it is nearly right. Nearly right is its own job, and that job is day two.
Day one goes to plan
By the evening of the first day there's usually a site. Routes, sections, a contact form that sends, a deploy, a domain pointing at it. Not a prototype. You could send someone the link.
Ask for a pricing page with three plans and you get one, markup and stylesheet together, with a responsive fallback that isn't stupid. Ask for a blog index and it comes back with dates and tags on it. This is what people mean when they say a website takes two days now. They're right.
Nothing is wrong yet on day one. Nobody has looked.
Day two is forty small wrong things
Then you open the site and go through it properly.
Day two isn't hard. It's long.
The gap under the hero is bigger than the gap under every other section. The middle plan card's title wraps onto two lines at 1280 and one line in your window, so the three cards end up different heights. The footer links are the same grey as the disabled button. The logo sits two pixels low against the nav.
None of that is hard. Each one takes seconds if you're already in the stylesheet. There are just forty of them, and they don't exist until the site does.
That day decides whether the site took two days or nine. It's also the day nobody puts in the estimate. Written down, it looks like nothing.
A fifteen second fix costs four minutes
Take one thing off that list and watch what it costs.
You see it in a second. Then you have to write it down: which section, which element inside it, which side the space is on, how much less. Then that the phone layout is fine and shouldn't move. Fifty words if you're careful.
Then you wait. Reload, look. Sometimes it landed on the wrong element, because the section is three wrappers deep and your words don't match what the code calls them. So you write it again.
The change was never the expensive part. Saying which change was.
Big items don't have this problem. A feature is worth a paragraph, and a paragraph describes behaviour well. Two pixels of space is not something a sentence is good at.
You still have to know it's a margin on one element and not padding on another. That half of the job never moved to the agent.
A day only holds so many turns
You and the agent take turns. While it writes the fix, you're waiting to check it. Nothing else moves.
A day holds only so many of those turns. That number is your schedule, whatever happens inside each one.
So a faster model doesn't buy day two back. Fewer turns does. Make the change where you can see it, then hand over the change instead of a description of it.
Point at it instead of describing it
That's the job Pixy does. Put the tag on your own site, or install the Chrome extension and skip the code. Press ⌘⇧E and the page you're looking at becomes the page you're editing. Your CSS, your content, your breakpoints, at the width you're sitting at.
What opens looks like a document. Drag a block where it belongs. Click text and type. Swap a picture with Replace. Undo and redo from the bar at the bottom. Expert opens the full canvas when a fix needs handles, the properties panel or the CSS and HTML tabs.
Every change is written down the same way: the element, the property, the value before and after, and the width you were at. Make a fix at 390 and it belongs to the phone layout, not the desktop one. Spacing that belongs to a rule goes on the rule, so every match updates instead of one card drifting away from the others. What you tried and took back stays in this browser, because only the changes you keep go any further.
Done this way, the fixing takes about as long as the looking. And the whole list leaves in one batch instead of forty messages.
The two days in order
The order matters more than the hours.
- Real content on day one
Placeholder text hides half the layout problems. Pasting the copy in early costs less than redoing the layout later. - Every page standing before you improve any of them
A section you polish early is usually a section you move again. - Look at the whole site in one sitting
Walk it at two or three widths and write down everything wrong before you fix anything. - Fix what you can see by hand
Spacing, size, wording, order and pictures are all faster to move than to describe. - Send the batch once
Hand the list over in one go, then read the result instead of trading forty messages.
None of that is about typing faster.
So, two days?
For a small site, yes. One condition: day two goes on looking at the site, not writing about it.
A shop with a catalogue, a login and five years of stylesheets was never a two day website. It still isn't.
What changed is which half is slow. The code stopped being the bottleneck when the agent started writing it. What's left is the gap between seeing something wrong and getting it changed. Right now that gap is made of sentences.
Take the next thing you build. Do day one the way you already do it. Then work day two with your hands, and let your agent pick the whole list up in one call.
Enough theory. See what slows design down.
Try Pixy on this page, or connect your own website and explore it there.