What Clients Say They Want vs What They Actually Need

The Most Expensive Decision Is Made Before Any Code

In the thirteenth episode of the CMS Conf Podcast, Piotr Cezary Wojciechowski, co-founder of Softwareness, makes an argument that reframes where the risk in a web project actually sits. The decision that determines whether a build succeeds is not the choice of framework, CMS, or hosting. It is made earlier, in the gap between what a client says they want and what their business actually needs. A client arrives asking for a large online store. The technically faithful response is to build a large online store. The correct response, Piotr argues, is to first establish whether a store is the right system at all.

If you run a business that is about to commission a website or an e-commerce build, Softwareness is worth a direct look. The agency starts from your business rather than from a template, runs a structured discovery before quoting a solution, and is candid when a cheaper, simpler path serves you better than the expensive one. You can see their work and reach the team at softwareness.org - the kind of partner that tells you what you need to hear before you spend, not after.

Two Project Managers Instead of a Seller and a Builder

Most agencies form around a complementary pair: one person sells, one person builds. Piotr and his business partner Michał inverted that model. Both came from project management backgrounds, met at the same university and student organization, and worked the same role at the same company before founding Softwareness. Neither started as the designated salesperson or the designated engineer.

Piotr is direct about the trade-off this creates. A sales-and-tech pairing has an easier start: deals come in immediately and someone can deliver them. The PM-and-PM pairing carries more early homework, since both founders had to grow into sales and into technology rather than inherit one ready-made. The compensating advantage is structural. Having both run projects end to end, they have seen the entire pipeline from the inside, from sales through design and development to client satisfaction and ongoing contact. The claim is that this full-process visibility, the knowledge of where bottlenecks and risks actually sit, becomes the durable advantage as the company scales, even if it costs more at the outset.

Discovery as a Filter Against Over-Building

The phrase on the Softwareness site, software that understands your business, is a cliche on most agency pages. Piotr treats the underlying behavior as the actual product. The standard flow begins with a discovery phase: a client presents an idea, the team asks questions, draws out information, runs a brainstorm, and only then proposes a solution. Inside that phase sits what Piotr calls a client deep dive, a deliberate round of questions designed to test whether the stated request matches the underlying need.

He warns clients in advance that this can feel uncomfortable, because the answers sometimes invert what they believed they wanted. The failure mode this guards against is over-building. A client who asks for a large Shopify store may, on inspection, need a stronger marketing strategy and a much simpler, cheaper system. Sometimes a landing page wired to a single tool that handles the entire purchase flow is enough to start. The recurring damage Piotr describes is the client who paid a specialist or agency for something enormous, ended up with a product that works but does not fit, and had no conversation early enough to prevent it. The discovery phase is the mechanism that surfaces that mismatch before money is committed.

The scale of the discovery adapts to the scale of the project. There is no fixed template applied to every engagement. A client in a genuine hurry gets an accelerated process, compressed but not hollowed out, so the essential question - what does this business actually need - still gets answered.

Choosing Technology by Working Backward From the Need

Technology selection follows the same logic. When a technical client specifies a stack with clear reasoning, Piotr will probe lightly and then defer, even if he would have chosen differently, because the client understands the trade-offs. When a non-technical client arrives attached to a specific technology because it sounded impressive, was popular, or was recommended by an acquaintance, he challenges it openly. The probing usually exposes a real requirement underneath the surface preference, lower maintenance cost or one specific feature, and that requirement, not the named tool, becomes the basis for the solution.

The organizing model is the minimum viable deliverable. Rather than commit a client to a large build on an untested assumption about their customers, Softwareness ships the smallest useful version first, lets the client see it work, and then chooses a direction from evidence. Piotr frames it through a sports analogy: instead of buying a tennis racket, court membership, and a year of commitment before the first session, you buy the shoes, see how they feel, and decide from there. The architecture is deliberately staged to keep the early commitment, in both time and money, low enough to change course.

The Stack and the Handover

On tooling, Softwareness leans on Shopify for e-commerce and Webflow for websites, with a growing share of custom development written with AI assistance. The custom path is positioned as more capable than no-code for projects that need room to grow, using AI tools to write and verify code faster and more precisely. Content management is matched to the build: Shopify and Webflow each ship their own editing layer, while custom projects connect Sanity as a headless CMS.

The operational principle after launch is to give the fishing rod rather than the fish. Maintenance agreements exist, from fixed monthly support hours to ad hoc help, but every client is trained on their own tool so routine content changes do not require a developer. Piotr contrasts this against a familiar failure pattern, including with WordPress: an outside specialist builds an impressive site with modern tooling, then the owner cannot change a font color without going back to the programmer. He cites a project where an AI-generated site could not handle a complex sixteen-page form and had to be migrated to WordPress anyway. The lesson he draws is about limits and ownership, not about which tool wins.

AI as a Multiplier, Adopted by Testing

Piotr’s position on AI is consistent with the rest of his reasoning: it is a tool, and a tool amplifies existing skill rather than substituting for it. A developer with ten years of experience plus AI delivers far more than a beginner expecting AI to do everything. The adoption process is empirical. New tools and techniques are tested internally first, on the team’s own landing pages and on transparent barter projects, and only brought to paying clients once the agency is confident. His most-relied-on tool is Claude Code, used to connect applications and build automations, layered with dictation and other workflow accelerators that compound small time savings across every prompt.

The same maturity framing closes the discussion of client discovery itself. Piotr maps it to seniority. A junior executes instructions. A senior probes beyond the stated request, pulls out the real need, and designs the optimal solution. The willingness to ask uncomfortable questions, backed by written scope and transparency when a client insists on their own path, is not a personality trait. It is a sign of professional maturity, and it is the through-line connecting every decision Softwareness makes.

If your next project deserves that kind of partner, this is the moment to act. Softwareness builds e-commerce and websites that start from your business rather than from a guess, and they will tell you when a smaller, cheaper solution is the smarter one. Reach the team through softwareness.org or follow Piotr’s founder-on-the-road journey at founderwdrodze.pl. Bring them the request you think you have, and let the discovery phase find the one you actually need - before you spend on the wrong thing.