"We are finished!" Three words that triggered very different reactions during our website relaunch: relief from the dev team, pride from the UX/UI designer, and slight panic from me. On September 24, 2026, I spoke at the Agile Tour Vienna at Europahaus Wien about this project. Why did I speak at the event? I'm not an expert in agile methods; I'm the Head of Marketing at LEAN-CODERS. In this project, I was the person who ultimately had to work with the result. This is the story, along with the question that has occupied me since then: When is something actually finished?
A brief context: The Agile Tour Vienna was sold out with around 300 participants. Besides the main stage, there was a side stage in the seminar room, and that’s where my slot was. Between 50 and 60 people found their way to me. For my very first presentation ever, that was more than I had hoped for. I was super happy. Adrenaline level: somewhere between a football kickoff and a live broadcast.
The Initial Situation: New Brand, New Website, a Blind Spot
LEAN-CODERS underwent a rebranding last year: new colors, new fonts, new logo, and a new brand world that finally matches our DNA. We are not conforming and not quiet. We are wild, cheeky, loud, and we like to provoke. The old design was far too tame and a bit boring. So, a new website was needed with the new brand. A website relaunch as an internal project, with our own people and short paths. Easy peasy, we thought. Spoiler: It was neither easy nor peasy.
To kick off the talk, I asked the audience via QR code for whom we were actually building the new website. The answers were diverse: Most frequently mentioned were "customers," closely followed by companies, SMEs, small businesses, and job seekers. Also mentioned were applicants, potential new employees, developers, software engineers, CTOs, CFOs, and department leads. Start-ups, freelancers, craft businesses, and IT-remote companies were also mentioned. Some thought of investors, the press, or competitors. And one answer was particularly precise: "Women between 30 and 40." We are still puzzled about what that person intends to do with our website.
Our own list (which I created) looked quite similar at the time: CTOs, CIOs, CEOs, tech leads, solution architects, head of IT, POs, PMs, senior devs, and applicants. All correct. But one target group was missing, both in the room and in our project: the editor who fills the system. That’s me.
Act 1: The Team Builds, I Watch
In the weeklies with UX/UI design and development, I saw Figma designs. Whole subpages, neatly modularly built. We discussed functions and modules per page. I didn’t open the CMS even once during that time.
In hindsight, that was the core of the problem. I saw pretty pictures, and my expectations grew with each weekly. At the same time, I didn’t know what to ask. If you’ve never touched a system, you don’t know what you don’t know.
Act 2: The Harsh Awakening at Handover
Day 1 of the handover: "We are finished. Let us know if you need help."
The homepage was there, but the other pages were not. I had the Figma design in mind and sat in front of the Strapi interface, our headless CMS. I stumbled right at the cover of the homepage: one setting was wrong, and the component disappeared. I initially saw nothing at all. White is also a color.
There was documentation, an extensive Confluence page with 5,946 words. That’s almost the length of a technical bachelor’s thesis. Well-intentioned, but under time pressure, not the help I needed.
Why didn’t I just ask? I did, but each module worked differently. There were 48 modules, including ten different grid modules. At some point, I felt like I was asking every ten minutes and thought to myself: "I can’t be that dumb." On top of that, there were asynchronous working hours and a deadline that couldn’t be moved.
On paper, I had 14 working days for the content. In reality, two days went to understanding the system, two days for migration to the live environment, and two days for rewriting because a new sales strategy with twelve new services came in parallel. In the end, it was about 155 hours in three weeks for content creation, page building, and inputting, alongside my other tasks. For comparison: A working month has about 173 hours. We ended up with 23 pages.
The time evaluation from our project retro clearly shows the imbalance. Of the total duration of 6.6 months, 38% went to design, 53.2% to implementation, and 8.8% to content. The ratio of development to content was 4.9 to 1, more like an app than a website. The content was like the side salad next to the schnitzel: planned, but never the main thing. The feedback loops with stakeholders were reduced or completely omitted due to time pressure. A very poor prerequisite for aligning stakeholder expectations.
Act 3: The Slightly Different Happy Ending
The story still ends well, just differently than expected. Frustration turned into ownership. I know the system inside and out today because I had to fight my way through it.
Technically, the website is top-notch: under 0.5 seconds loading time, 100/100 in Lighthouse SEO score, and 100/100 in Lighthouse accessibility score. It loads so quickly that we had to implement page transitions to keep the human eye up. Luxury problems. We are working on a support group.
The most important insight came from the retro: Six people were involved in the project, from UX/UI design to marketing, SEO/GEO, and development to our COO as a stakeholder. That also meant six different meanings of "finished." No one did anything wrong. We just never collectively defined what "finished" means.
Definition of Done in Scrum: Briefly Explained
In Scrum, the definition of done describes what state an increment must reach to be considered complete. It is a shared, binding agreement within the team, for example: code reviewed, tested, documented, deployed. As long as a point is open, the work is not "done."
The strength of the definition of done is transparency. Everyone knows what "finished" means. Its typical weakness is shown in our project: it is usually written from the perspective of the team that builds, not from the perspective of the people who will work with it afterward.
When is a project really finished?
For the dev team, the project was finished when the code ran. For design, when the components matched the Figma design. For me, the project would only have been completed when I could independently build a page without fear of breaking something. Or can a website ever really be "finished"?
All perspectives are correct. That’s why technical completion alone is not enough as a criterion once a project is handed over. A project is only truly finished when the people taking it over can work with it.
Lessons Learned: Five Things I Would Do Differently Today
- Finished ≠ finished. Six participants, six meanings. If you don’t explicitly clarify what "finished" means, you will clarify it at the handover, and painfully.
- Customers don’t know what they don’t know. I couldn’t ask questions about the CMS because I had never seen it. Proactive communication alleviates this: Show the system early, even if not everything is finished.
- Customers don’t speak your language. Slug, metaRobots, Edge to Edge: everyday terms for you, foreign words for others. I long thought of a slug when I heard "slug." It is, by the way, also that. Translate it before someone has to ask.
- Controlled failing is your friend. Let customers make mistakes in a safe environment. Once someone has "broken" a component on staging and repaired it, they lose the fear of the live system.
- Define your target audience as detailed as possible. This includes not only the visitors of the website but also the editors who manage the system daily.
Definition of Done Example: Three Criteria We Missed
My suggestion from the talk is not a new definition of done but an extension to include end-user criteria. As a definition of done example for every project that will be handed over:
- Onboarding has taken place. Not just offered, but planned as a fixed part of the project.
- The documentation was handed over, and before the customer starts, not parallel to the deadline.
- Ownership is established. The person taking over has built a page or a dataset themselves and learned through controlled failing.
Only when these three points are fulfilled is the project "done."
Website Relaunch Checklist: What Must Be Completed Before Handover
From our lessons learned, a short list has emerged that I recommend to every team before go-live:
- Editors are defined as their own target group
- Content was planned from the beginning (content first), including keyword strategy for SEO and GEO
- Time for content is realistically planned, not as a leftover after development
- The CMS was shown to the editorial team during development
- Technical terms in the system are explained
- There is a test environment for safe experimentation
- Feedback loops with stakeholders are firmly scheduled, even under time pressure
- All participants have jointly defined what "finished" means
Conclusion: Finished is when it’s finished for everyone
Our website relaunch was technically a success and a lesson for people. The website is fast, accessible, and easy to find, and it will continue to be optimized because a website is never completely finished. What I took away most is: "Finished" is not a property of a product, but an agreement between people. Those who make this agreement early and consider the people who will ultimately work with it save themselves a lot of frustration.
And if you’re wondering whether your project is really finished: ask the person who has to take it over. And bring coffee.
Do you have a website project coming up? We think about the handover from the very beginning.
