drebin_proposal_final2.html, not the earlier proposal versions. It promised Phase 1 design in 5-7 weeks, Phase 2 programming in 6-8 weeks, and a 10-13 week total approval-to-launch window with overlap. With Day 0 on May 1, 2026, the client-facing launch ceiling is July 31, 2026. The project is late-stage design polish with most desktop sections complete, but homepage/mobile approval, written sign-off, tech sheets, and developer booking still need to be locked before development.Evidence Used
Primary communication channels reviewed: DD website design with Ivan, DD website design with Ivan, Mira, DD website design with David, Ivan, Mira, Ivan K, iBrain call transcripts, Asana, the approved HTML proposal/brief, internal start records, and the June 1 Ivan brief with screenshots.
Database records checked: communication_master.db, asana.db, invoices.db, email_ingest.db, teams_historical_access.db, and internal project-start records. The usable current DD sources are Telegram/call project data, Asana, invoices, proposal files, and extracted project context. The local email ingest is limited, and the Teams/Skype archive is historical through March 29, 2025, not a live 2026 DD source.
Source inventory result: 809 local files matched the Drebin/DD website search across Desktop, Documents/iBrain, Downloads, and the iHouseDesign Google Drive workspace. The full raw source register is intentionally not included in this team-facing version because local file names and paths may contain internal notes or unrelated private material.
Approved Proposal Schedule
The HTML proposal/brief sent to David is a primary source for this schedule. The Asana project note says David approved the project's brief on a group call and links to the proposal URL. The controlling local export for this schedule is drebin_proposal_final2.html; earlier exports are treated as drafts unless separately confirmed.
| Proposal item | Client-facing commitment |
|---|---|
| Scheduled calls | Two scheduled Zoom calls per week during active design, with screen sharing and recording. |
| Approval gates | Written approval by email at every gate: design before development, staging before launch. |
| Specifications | Tech sheets/specifications with every designed page before development. |
| Phase 1 design | 5-7 weeks. |
| Phase 2 programming | 6-8 weeks after Phase 1 design approval. |
| Overlap | After Phase 1 approval, development can begin while deferred Phase 2 sections continue in design. |
| Total duration | 10-13 weeks from written approval to launch, assuming client approvals within 48-72 hours at each gate. |
The April 24 call transcript confirms David was reading this document on the phone. He pushed back on the timeline feeling too long, and Arseni explained that design/build overlap was intended to shorten the calendar. David then accepted the direction in principle, while still wanting the timing to move faster. The operative promise should therefore be read from the shorter final2 schedule, not from the earlier 11-15 week draft.
Day 0
Day 0 is May 1, 2026. An internal project-start record confirms the DD Website Redesign was ready to commence. Financial figures are intentionally omitted in this team-facing version. Under the final2 10-13 week promise, the approval-to-launch window runs roughly from July 10 to July 31, 2026.
An earlier Phase 1 planning note appears in May 10 context/handover material and was marked not confirmed in writing. It is not the confirmed start evidence used for Day 0.
Chronology
March 25
David framed the redesign around commercial positioning: fewer categories, stronger calls to action, visible floor pricing, The List, and a more serious collector experience.
April 19-20
The team converted David's relaunch idea into a Phase 1 scope: homepage, collections, galleries, press, and access/the list. Ivan estimated 5-7 elapsed weeks because approvals and client pauses would stretch the working time.
April 24
David reviewed the HTML proposal/brief by phone. The controlling final2 proposal schedule said Phase 1 design would take 5-7 weeks, programming would take 6-8 weeks after Phase 1 design approval, and the total launch window would be 10-13 weeks with overlap. The call also clarified homepage video direction and tech sheets as the bridge from design to development.
April 26-May 10
The project moved through language approval, content reduction, tagline drift, and homepage video/storyboard planning. The team learned that content selection is a major bottleneck because many available exhibition images are not strong enough for the homepage reel.
June 1
David gave strong verbal direction: larger scroll arrow, simple readable menu, Connect approved, no broad House of Drebin branding, no Virtual label, VR inside Galleries as one combined video, Podcast renamed to In Conversation, and Michelle's block on Connect.
June 9
David asked for a timeline update. Arseni said the project was on schedule and committed to send a mobile page update or HTML demo on June 10. David referred to the website as a meaningful investment.
June 10-16
Asana shows most desktop design sections completed. Mobile demos appeared, but real-device issues surfaced: small text, spacing, iPhone/Android differences, and hamburger/menu behavior.
June 19
David reviewed the mobile homepage and hamburger direction, said it looked great, and approved the bottom menu direction verbally. He added constraints: no dates, no gallery names, no individual gallery branding in the reel, no violin-player footage, and focus on images, art, and broader events.
June 20
Internal discussion shows the project is not behind in design so much as behind in approvals. Homepage structure and font weight are still being debated before final client sign-off.
Visual Information
| Visual source | What is visible | Decision it supports |
|---|---|---|
| June 1 Ivan brief assets | Hero arrow, homepage versions, typography, galleries, Connect, collections | Post-presentation fixes and section confirmations |
| Hero arrow screenshot | Arrow is too subtle | Make scroll action obvious |
| Biography typography comparison | Thin versus heavier readable type | Use more readable type |
| Galleries/VR screenshot | Gallery representation and VR/media placement | VR belongs inside Galleries |
| June 16-19 mobile screenshots/videos | Mobile homepage, galleries, hamburger, small title text | Real-device readability and menu behavior |
| Gallery reference screenshots | Major gallery homepage/reference pages | Luxury gallery hierarchy and restraint |
Risks
- Unmatched commitments. June 10 mobile demo/update and June 16 plan/current-state note need a clean completion record.
- Verbal approvals. Most meaningful approvals are verbal or internal Asana notes, not written by David.
- Developer not engaged. Dev access is prepared, but development should not be treated as started.
- Timeline slip. The controlling final2 proposal used a 5-7 week Phase 1 design window and a 10-13 week approval-to-launch estimate. The 5-7 week design window has passed, the homepage task due June 11 is still open, and a September launch is not supported by the client-facing promise unless David approves a revised timeline.
- Tech sheets. They were shown/explained to David on April 24 and should remain in the schedule before development.
Recommended Next Step
Send David one written approval recap: what he approved, what remains open, what will finish by June 22-23, and when development can start. That is the missing bridge between strong creative progress and a controlled build.
Where we should be.
The final2 proposal baseline says Phase 1 design should have been locked by Friday, June 19 and the whole project should launch within 10-13 weeks from approval. As of Sunday, June 21, the design gap is small in isolation, but the total-window risk is not small: the July 31 promise ceiling leaves almost no slack for a full custom CMS build unless development is compressed or the scope is reduced.
Baseline check
Read: measured only against Phase 1 design, the variance is still manageable. Measured against the final2 approval-to-launch promise, the risk is serious. If written design lock lands Tuesday, June 23 and development starts July 1, the team must either compress scope and QA into the July 31 ceiling or get David's written approval for a later build window.
Why the variance exists
Working Sundays helped the creative work move, but it did not close the production gates. The schedule is not measured by effort alone; it is measured by written approval, tech sheets, developer booking, and handoff readiness. Arseni's Sunday work reduced the creative gap, but the approval system still stayed too dependent on private calls and memory.
| Bottleneck | Who is slow | Why | Evidence | Fix |
|---|---|---|---|---|
| Approval conversion | Arseni / art direction gate | Client calls produced real decisions, but decisions were not turned into same-day written recaps, approval-board updates, and locked design handoffs. | On June 9, Mira was still asking what David approved, while Arseni said David had already liked the homepage. | After every David call, publish one written recap: approved, open, changed, next owner, next date. |
| Project management control | Mira / PM gate | Mira cannot replace Arseni on David-facing creative approval, but the PM system did not force missing approvals into a visible blocker fast enough. | Mira said she was waiting for Arseni to tell her what David approved. Asana still shows the agreed time-period task open. | Mira owns the approval board, meeting cadence, blocker log, and weekend staffing asks. If a call happens privately, she must request the transcript/recap before work continues. |
| Homepage and mobile polish | Ivan / design production, narrowly | Most sections are done, but homepage, mobile menu, real-device readability, and reel constraints remained active after the design-lock baseline. | Asana shows most desktop sections completed June 9-10, but homepage with slideshow remained open after its June 11 due date. | Timebox variants, test on real devices earlier, and freeze the homepage/mobile system once David signs the written recap. |
| Client approval rhythm | David / client gate | David gave useful verbal approvals but also works informally and adds constraints late, which makes written approval more important, not less. | The proposal called for two scheduled Zoom calls and written approval gates; the project drifted back into informal call approval. | Keep David-friendly calls, but follow each call with written confirmation and a 48-hour approval window. |
Recovery schedule
The serious production baseline is stricter than the earlier visual sketch. Programming starts only after written design lock, tech sheets, developer engagement, and estimate lock. CMS structure starts with programming. Content/CMS population follows once the structure exists. Testing begins during the build, then becomes formal cross-browser and real-device QA after feature-complete staging.
Read: the project is not failing creatively. It is failing the production discipline that lets a large website behave like a schedule. The final2 promise makes the recovery harsher: either launch a compressed/staged scope by July 31, or get David to approve a revised August build window before the old promise becomes a client-facing miss.
| Workstream | Start | End / target | Owner | Status | Gate |
|---|---|---|---|---|---|
| Written design lock | June 21 | June 23 | Arseni / David / Mira | IN PROGRESS | David confirms homepage, mobile, reel constraints, and section approvals in writing |
| Tech sheets and developer handoff | June 24 | June 30 | Ivan / Arseni | PENDING | Every page/state going to development has a clear design/spec sheet |
| Developer engagement and estimate lock | June 24 | June 30 | Arseni / Mira / developer | NOT STARTED | Developer is formally booked and estimate is confirmed |
| New CMS structure and staging setup | July 1 | July 11 | Developer | NOT STARTED | CMS fields, templates, staging environment, and admin paths exist |
| Programming: front-end and CMS implementation | July 1 | August 18 if full 8-week build is required | Developer | NOT STARTED | Final2 baseline says 6-8 weeks after design approval; this conflicts with the July 31 total-window ceiling unless scope is compressed |
| Content/CMS population | July 8 | July 25 | Mira / Arseni / developer | PLANNED | Compressed path requires core CMS structure and final content list immediately |
| Developer QA during build | July 21 | July 31 | Developer | PLANNED | Each section is tested as it becomes usable |
| Formal cross-browser and real-device QA | July 21 | July 31 | Developer / Ivan / Mira | PLANNED | Only possible inside final2 if QA overlaps the build |
| Client staging review and launch approval | July 25 | July 31 | Arseni / Mira / David | PLANNED | David reviews staging and gives written launch approval |
| Final fixes and launch preparation | July 29 | July 31 | Developer / Arseni | PLANNED | DNS, redirects, backups, analytics, forms, mobile, performance, and content freeze are checked |
| Launch window | July 31 | July 31 | Developer / Arseni | AT RISK, NOT COMMITTED | Latest date inside final2 promise; later dates need written client re-approval |
| Invoice gate | Evidence / current status | Serious schedule read |
|---|---|---|
| First redesign invoice | Invoice 1604 was issued May 1, 2026 and is marked paid in invoices.db. The paid-date field is blank. | This supports May 1 as Day 0. No amount is included in this shareable version. |
| Final/balance invoice | I found an Asana invoicing task but no due date, trigger, or sent invoice record for the final/balance invoice. | If this is a design-lock balance, schedule it after written design lock, target June 24-26. If it is launch/staging-based, schedule it around the July 25-31 staging/launch approval window. Arseni needs to confirm the trigger. |
Historical workflow read: older iHouseDesign website projects separate technical requirements and access, CMS structure, content integration, approved design implementation, final cross-browser/device QA, launch, and post-launch cleanup. Carter Dow, One Illuminates, David Martinez, Maquette, and LeDrew all point to the same lesson: production has to be managed as gates, not as a single vague "development" block.