What would you like to know before starting a website?

The number and type of pages, available content, languages, online store and integrations all affect the cost. Starting from scratch or rebuilding an existing site also makes a difference. After the brief, you receive a proposal for your project with the scope and price.

The timeline depends on the pages, features and materials we need to prepare. The proposal sets out the stages and dates, including when I need your content and feedback. A simple website and a store with integrations don’t follow the same schedule.

Yes. We agree early on what you want to update regularly: text, images, articles, products or pages. We choose a platform and editing setup that support those changes. Everyday content can be edited without a developer; entirely new pages or features are discussed separately.

Yes. We plan the pages and content for both languages, with separate URLs and language signals for search engines. The copy needs to be reviewed for each audience; translating the menu alone doesn’t make a complete bilingual website.

I start with your offer, customers and content, then define the pages and design. A custom website can also be built in a builder; the tool doesn’t require us to use a generic theme. We choose the approach based on what the site needs to do and how you’ll manage it.

No. I can help organise the pages, explain your offer and adapt existing materials. You confirm the facts about your business, services and promises to customers. We establish early on what material is available and what still needs preparing.

I design iOS and Android apps, native or cross-platform, from research to the final interface and design system.

An MVP (minimum viable product) is the smallest version of a product that solves the main problem and can be tested with real users. You start with one to learn quickly what works, before investing in every feature.

A strong signal is when the same information is copied between spreadsheets, email and several applications, approvals get lost or reporting requires repeated manual work. I map the process first and check whether an existing product can be configured before recommending custom software.

Yes. For web applications, portals, dashboards, CRMs and admin panels I can cover design and implementation. For native applications or systems requiring specialist infrastructure, I define from the start what I build directly and where an additional technical team is needed.

Absolutely. I have experience in collaborating, mentoring and helping your internal teams and third-party collaborators to ensure alignment and smooth execution for any goals that you want to achieve. Think of me as an extension of your team. That's exactly how I worked with clients like Adobe, Mercedes-Benz, Peace Nest and many others.

While I primarily take on larger projects, I occasionally accommodate smaller tasks, or a small freelance project within my ongoing retainer. Reach out with your details and I will see how I can help.

Yes. Tell me what your business does, who your customers are and what you want to achieve. Share your current website or examples you like, if you have them. The form only requires a project type, your name, email and confirmation that you’ve read the privacy notice; everything else can be left blank.

Yes, I take on projects from Romania, Europe and the US; I spent many years working for UK companies, including on platforms for sports clubs in the UK and the US. I work in Romanian and English.

You receive a prioritised list of problems, their impact, what is worth solving now and what can wait. The result helps you choose between optimisation, redesign, migration or a new product and can become the implementation brief for your team.

They are not required to begin, but they improve the quality of the conclusions. I can start with a heuristic review and business goals, then add analytics, session recordings, support tickets or interviews when they exist and are relevant.

We keep important URLs where possible. For changed URLs, we prepare redirects to the corresponding pages and check links, metadata and language versions. After launch, we monitor errors and indexing. Rankings can fluctuate, so I don’t promise a move with no traffic changes.

Before the project, we agree who updates the content and who handles technical maintenance. Depending on the solution, that may be your team, a technical provider or a support arrangement. We clarify what is handed over and what support is included, so you know what you can manage yourself.

First we look at what is getting in your way: editing, speed, integrations or maintenance. If the problems can be solved well on the current platform, I recommend improving it. Moving makes sense when the platform keeps blocking things that matter to your business.

Before moving, we inventory what exists and what needs keeping. We check what can be exported and transferred to the new system, then identify what needs rebuilding. Transferred content and data are checked before launch; I don’t assume every platform allows every feature to be moved.

Tell me briefly what you want to build or improve. I read your brief and follow up with questions; we can arrange a call if needed. You then receive a proposal with the scope, stages and price. You don’t need a technical plan ready.

A design system is a library of components, visual rules and interaction patterns that designers and developers use the same way. You need one when the product has many screens, several platforms or several teams, so the interface stays consistent and new screens are built faster.

Not every project needs a large study. I choose the method around risk and what is already known: interviews, analytics, support tickets, prototype testing or a rapid review. The important point is that critical decisions are not based only on internal preference.

I organise components, states and responsive rules into a coherent system, document important cases and review the product with developers. When I also cover implementation, I use the same rules directly in code, reducing the gap between prototype and released product.

No. We start with what the site needs to do, who will edit it, your budget and maintenance costs. Then we compare an existing platform with a solution built in code. You don’t need to know WordPress, Framer, Wix or other tools to start the conversation.

Yes, when the platform fits the project. I check what it supports for pages, editing and integrations, then build the design around your content and business needs.

Yes. The builder is the implementation tool, not the visual direction. Structure, components, interactions and responsive rules can be designed around the company's identity and content without starting from a generic theme.

We define in advance what changes frequently: copy, images, articles, projects, products or pages. I build controlled components and fields so the team can update content without breaking the layout or the SEO and accessibility rules.

SEO helps search engines understand public pages. AEO/GEO aim to make information clear and useful in AI answers too. The same SEO practices apply to Google’s AI features; there is no special technical requirement that guarantees inclusion. We plan public content with this in mind, while keeping private areas private.

No. We can work on accurate information, understandable pages and a sound technical structure, but we cannot control rankings or an AI assistant’s answer. We agree what to check and improve, without promises of guaranteed positions or citations.

Yes, SEO still matters: Google remains the main search engine, and AI assistants often rely on the same well-structured, indexed pages. Gartner predicted a drop in traditional search, but it is a forecast.

llms.txt is a proposed file that summarises a site's content for language models. Google has said it doesn't use it, but it costs little and may help other AI systems, so I recommend it as a secondary step, not a priority.

Most of the time, yes: product pages, filters, cart, checkout, speed and accessibility can be improved on the existing platform. Migration is recommended only when the platform blocks growth or integrations.

Shopify is a hosted platform with little technical maintenance and a monthly subscription; WooCommerce runs on WordPress and offers more control but needs more upkeep. The choice depends on catalogue size, local integrations (payments, shipping, invoicing) and who runs the store.

I start with the obstacles that directly affect purchase: product discovery, product information, trust, the basket and checkout. Analytics, internal searches and abandonment data show what deserves priority before a complete redesign.

Yes. I first document the data and steps that need to stay in sync, then verify the platforms' APIs and limitations. The integration is designed so orders and errors can be tracked without copying information manually between systems.

Technical fixes usually show after Google recrawls the pages, while content results take longer; the pace differs from site to site. I don't promise fixed rankings or timelines.

You receive the identified issues, affected pages, priority and technical recommendation for each one. I separate problems that block indexing or performance from secondary improvements and, when I have project access, I can implement the fixes and verify the result in search tools.

The cause may be technical, from indexing rules and canonicals to rendering errors, weak internal links or duplicate content. I first verify whether the page can be accessed, understood and indexed, then separate technical problems from a lack of relevance or authority.

I can implement the fixes directly when I have project access or work with your team through steps, examples and acceptance criteria. After implementation I verify the pages and important signals again; I do not consider an audit closed merely because a document exists.

It depends on your sector and company size: since 28 June 2025, the European Accessibility Act requires accessibility for certain products and services in the EU, including e‑commerce, banking, telecoms and passenger transport, along with their websites and apps. In Romania it is transposed by Law 232/2022.

Microenterprises providing services (fewer than 10 employees and no more than EUR 2 million annual turnover or balance sheet) are exempt from the service requirements; the exemption does not cover products. Even without an obligation, an accessible site is usable by more customers.

WCAG has three conformance levels: A (minimum), AA and AAA (highest); AA is the level required by most laws and standards, including EN 301 549. The W3C does not recommend AAA as a general requirement for entire sites, because some content cannot meet it; AAA is targeted at pages and flows where it matters.

EN 301 549 is the European accessibility standard for digital products and services; version 3.2.1 references WCAG 2.1 level AA for websites and apps. It is the technical reference used for the European Accessibility Act.

It depends on the number and complexity of the pages and flows audited (a checkout or customer account takes longer than a brochure page).

Yes. I can correct the design, components and code, or work with your team through examples, acceptance criteria and post-implementation checks. I separate quick fixes from issues requiring component or process changes so remediation can be planned realistically.