How long a deep tech rebrand and website takes
The nine to sixteen week sequence, what happens in each block of weeks, what makes a project overrun, and what a client has to supply to hit the date.
- Nine to sixteen weeks end to end, in one order: domain immersion first, then positioning and narrative, then identity, 3D and design, then the build and launch. How long each takes is set by scope, not by a fixed calendar.
- Fixed scope, fixed timeline, one price. The date is agreed before the work starts, not estimated as it goes.
- Where a project lands in that range is set by scope: how many solutions need explaining, how much detail and 3D the site carries, and how large the brand system has to be.
- Projects overrun for one reason far more than any other, and it is not scope. It is decision latency on the client side.
- Brand alone and website alone are both nine to sixteen weeks. They are not additive when run together, because the research stage is shared.
- Sprints come in two sizes: two to three weeks from ₹13L for a single page, five to six weeks from ₹15L for a campaign surface. Both are smaller objects, not compressed engagements.
Nine to sixteen weeks is the number we quote, and it is on most pages of this site. This is what actually happens inside it, and the specific things that make a project land late.
What does the nine to sixteen weeks actually cover?
End to end the order never changes: domain immersion first, then positioning and narrative, then identity, 3D and design, then the build and launch. What changes is how long each one runs, and that is set by scope rather than by a fixed calendar.
Those four blocks are the shape of the calendar. Underneath them, seven workstreams run, and most of them run at the same time as each other.
One product, one buyer, a settled position and a small brand system.
Several solutions to explain, a real content load, 3D on the product.
A platform, deep specification, a full 3D range and sub-brands.
One landing page, its visual identity and its messaging, packaged together. The exception, not the offer.
A campaign or launch surface with the visual language and messaging it needs, on a position that is already settled.
Same seven streams in all three. A block is a week, and the number on the right is how long that stream takes in that engagement. The 9 week version is not the 16 week version with stages removed: it is the same stages, shorter and overlapping harder. That is why 16 weeks holds 37 weeks of work and 9 holds 17.
The two sprints at the bottom are different objects rather than shorter engagements. Each packages a single surface with the visual language and messaging that surface needs, which is possible because it is one page or one campaign rather than a site, on a position that is already settled. Ask for a brand and a whole website in three weeks and the answer is no.
All of these assume founders plus one or two key people signing off. Where a larger team is involved, add one week to the shorter engagements and two to the longer, which can put the finish just past sixteen, and about a third to the cost. The planner on the home page works that out for your own scope.
That is the full sequence, brand through live website. Brand alone is nine to sixteen weeks. Website alone is nine to sixteen weeks. Run together they are still nine to sixteen, because the immersion and positioning stages feed both and only happen once. Two separate engagements, six months apart, cost more and produce a website that argues slightly differently from the brand.
The scope and the date are fixed before anything starts. Not a day rate, not an open-ended retainer.
What decides whether it is nine weeks or sixteen?
Scope, and it is knowable before we start.
The range is not hedging. It is the difference between companies with one product and one buyer, and companies with several. What moves a project towards the top of it:
How many solutions and industries there are to cover. A single product with one audience is a different job from a platform with four modules, each sold to a different function, or one product sold into four industries that each judge it differently. Every additional thing that needs its own argument adds pages, adds structure and adds review. Four or more of them starts at twelve weeks whatever else is true, because each one needs its own case made.
How much detail the website has to carry. Some categories are settled with a claim and a diagram. Others need specifications a specialist will read closely, comparison tables, and evidence for every number on the page. That is writing and reviewing time before it is design time.
How much 3D there is. A single hero render is not the same as a full product range, an exploded assembly, a scroll-driven sequence and a set of scene renders. 3D is the component of this work that scales least like the others, because each asset is modelled rather than laid out.
How large the brand system has to be. A company that needs a logo, a palette and a type scale finishes sooner than one that needs sub-brands, product naming, a full component library and rules for a booth, a deck and a datasheet.
Whatever is genuinely complicated about your particular case. Claims that have to clear legal or compliance before they can be published, a disclosure calendar, several stakeholders with real veto, a technology that takes a week to understand properly.
None of these are discovered mid-project. They are what the audit call is for, and they are why the quote names a date rather than a rate.
What happens in week one?
We learn the technology well enough to argue about it.
That means reading the spec sheet, the deck, the tender response and whatever internal document actually explains the mechanism, then sitting with the engineer who owns it. Not the marketing lead, the engineer. Week one is where most of the eventual quality is decided, and it is the week clients are most tempted to compress because nothing visible is produced.
For deep tech this stage is longer than it would be for a software company, and that is the point. A studio that skips it produces work that describes your sector accurately and your company not at all.
Why do positioning and narrative come before design?
Because design is a set of answers, and the questions have to be settled first.
Weeks 2 and 3 decide which category you are read into, which buyer the page is written for, what you claim and what evidence makes the claim survive contact with someone qualified to check it. Those decisions constrain everything downstream: the identity, the 3D, the site architecture, the copy.
Changing a position in week 3 costs a conversation. Changing it in week 9, with identity applied and a build underway, costs the build. The order is not administrative. It is the difference between a brand that holds and one that gets quietly rewritten a year later.
When does the website build start?
Weeks 9 to 16, after design is settled.
Building earlier feels faster and is not. A build that starts against unfinished design absorbs every subsequent design change as rework, and the rework is invisible until the end, when it arrives all at once as a slipped launch.
If the site carries custom 3D, the modelling runs in parallel from around week 4, because 3D has its own sequence and cannot be compressed into the last fortnight. That parallel track is the main reason a 3D-heavy site is not slower than a flat one.
What makes a project take longer than sixteen weeks?
Decision latency, almost every time.
Not scope, not complexity, not the technology. Time spent waiting for an answer about whether a claim is defensible, or which of two positions the founders prefer, or whether legal is comfortable with a number. The work stops, the calendar does not.
The pattern is consistent enough to plan around. Companies that name one decision-maker and one technical reviewer at kickoff land on the date. Companies that route every question through a committee do not, and the overrun is roughly proportional to the number of people who have to agree before anything is signed off.
The second cause, distantly, is a disclosure calendar that moves. That is legitimate and we plan for it, which is a different problem from a decision that simply has not been made.
Can it be done faster?
Sometimes, and it costs something specific.
A fundraise or a tender deadline occasionally requires a compressed run. What compresses is exploration: fewer routes explored, fewer alternatives to compare, decisions made from one strong option rather than three. What does not compress is technical review, because that is the stage that keeps the work factually correct, and skipping it in deep tech is how a brand ships a wrong number to an audience that will catch it.
If the deadline is real, say so at the audit call rather than in week six. A schedule designed to be fast is a different schedule, not the same one hurried.
The genuinely short engagement is a different shape again, and it comes in two sizes. A two to three week sprint, around ₹13L, packages one landing page with the visual identity and messaging that page needs. A five to six week sprint, from ₹15L, does the same for a campaign or launch surface rather than a single page. Neither is the full sequence hurried: the stages are the same, but the surface is one page or one campaign rather than a site, and a single surface can carry a visual language that a whole company cannot. Both assume the position is already settled. Ask for a brand and a whole website in three weeks and the answer is no.
What do you need from us to hit the date?
Three things, and none of them is a brief document.
Access to the engineer who owns the mechanism, for a few hours across the engagement. One named decision-maker who can approve a position without convening anyone. And your disclosure calendar, so launch is sequenced against your PR, tender or funding dates rather than colliding with them.
That is genuinely most of it. Companies supplying those three hit the date at a rate that has nothing to do with how complicated their technology is.
What happens after launch?
The site is yours, and so are the files.
The handover includes the brand book, source files and, for a Webflow build, a team that can edit without coming back to us. Where the build is static, we hand over the repository. The specific question of who owns what at the end is answered the same way on every page of this site, because it should not be interesting: you do.
Written by Mejo Kuriachan. More in the blog, the glossary and the FAQ.