"Why are you building for ISO 27001 compliance when you only have 3 customers?"

Because retrofitting security is 10x harder (and more expensive) than building it right from the start.

Thread on building enterprise-grade from day 1 🧵


We don't have ISO 27001 certification yet.

(Certification costs ~€50K and takes months. We're bootstrapped.)

But we're building AS IF we already need to pass the audit.

What this means in practice:

All data encrypted at rest & in transit

Role-based access controls from day 1

Audit logs for every action

Data residency options (EU/US)

Regular security reviews

Incident response procedures documented

Even with 3 customers.

Why?

Because we're targeting mid-market manufacturers.

They ask about security on the first call.

Not "Do you have ISO 27001?" (they know we're early)

But "Are you BUILDING for it?"

That's the real question.

Same with EU AI Act compliance.

It's coming. It's mandatory for certain use cases.

Building AI systems that will never pass compliance = building technical debt.

Better to design for it now, certify later.

The cost:

~20% slower initial development

More architectural discussions

Can't take shortcuts

More documentation

The payoff:

Enterprise customers trust us early

No "security debt" to fix later

Easier to fundraise (investors like seeing this)

Certification will be straightforward when we're ready

If you're building B2B SaaS for regulated industries:

Don't wait until you "need" compliance.

Build like you already have it.

Your future self (and your customers) will thank you.

What compliance/security question surprised you most from early customers?

Building Security from Day 1

The question isn't "Is ChatGPT useful for R&D?"

It absolutely is.

The question is: "Is ChatGPT enough for R&D?"

And the answer is no.

R&D teams need:

– Systematic data collection (not ad-hoc chats)

– Team collaboration (not solo conversations)

– Memory that compounds (not context that resets)

– Full data sovereignty (not training data for OpenAI)

Generic AI is a starting point, not a solution.

Building Wicely for teams who've hit ChatGPT's ceiling.

Have you hit this ceiling yet? What was the moment you realised you needed more?

ChatGPT for R&D

"Why don't R&D teams just use ChatGPT for technology research?"

I get this question constantly.

Here's why generic AI isn't enough for serious R&D work 🧵

ChatGPT is great for exploration.

But R&D isn't about one-off questions. It's about systems.

You need to:

– Collect data systematically (internal + external)

– Store it in structured, searchable ways

– Build institutional knowledge over time

– Get insights from accumulated context

ChatGPT can't do this.

Problem 1: Context limits

Your research grows. Your context grows.

ChatGPT: "This conversation is too long. Please start a new chat."

Now you've lost all the previous context. You're starting from scratch.

Enterprise R&D needs memory that compounds, not resets.

Problem 2: Collaboration

R&D is a team sport.

ChatGPT is built for one person asking questions.

What about:

– Sharing research with colleagues?

– Role-based access to sensitive data?

– Audit trails of who found what when?

– Building on each other's discoveries?

You need proper enterprise tools for this.

Problem 3: Research workflows

ChatGPT gives you answers to questions.

R&D needs structured analysis:

– Systematic patent monitoring

– Trend identification across datasets

– Comparison frameworks

– Traceable sources for every claim

Generic chat interfaces aren't built for this. Analyst-grade workflows are.

Problem 4: Data access

ChatGPT can't:

– Query patent databases with advanced filters

– Access your internal company documentation

– Monitor competitor movements in real-time

– Connect to specialised technical APIs

Purpose-built tools have the right integrations. Generic LLM doesn't.

Problem 5: Data security

ChatGPT's terms: Your inputs may be used to train their models.

For R&D teams handling:

– Proprietary research

– Competitive intelligence

– Patent strategies

– Confidential product plans

That's a non-starter.

What serious R&D teams actually need:

✓ Systematic data collection & storage
✓ Team collaboration with proper access controls
✓ Context that grows over time, not resets
✓ Analyst-grade research workflows
✓ ISO 27001 & EU AI Act compliance
✓ Full data sovereignty

Not "AI that chats." AI that works like an enterprise system.

This is what we're building at Wicely.

Not another chatbot.

A research intelligence platform designed from the ground up for R&D teams who can't compromise on privacy, structure, or collaboration.

What's the biggest gap you see between ChatGPT and what your team actually needs?

Why ChatGPT Isn't for R&D

We store everything in GitHub: code, specs, docs, prompts, even product strategy.

Why?

Because Claude Code can read the entire context.

When we ask: "How should we implement feature X?"

It reads:

– Existing code patterns

– Architecture decisions

– Product requirements

– Previous similar features

Then suggests implementation that's consistent with everything we've already built.

This is the real power of AI coding assistants.

Not "write code faster."

"Maintain consistency across a growing codebase with a tiny team."

How are you using AI in your development workflow?

GitHub: Power of AI

In 100+ customer interviews, the best question I asked wasn't about features.

It was: "Walk me through your last frustrating day at work."

Not "What frustrates you?" (too abstract)

"Your LAST frustrating day" (specific, recent, real)

People don't remember patterns. They remember Tuesday at 15:00 when everything went wrong.

That's where the real problems live.

Uncover Real Problems

Reading "Advantage: Culture" by Jaïr Halevi and it's bringing back memories from my time at @ERNI together with @gregmarlop.

They did a few things remarkably well. Thread on what stuck with me 🧵

1. Psychological safety wasn't a buzzword

It was operationalised:

– Weekly team retrospectives (not just on projects, on how we worked together)

– "No question is stupid" was actually lived, not just said

– Mistakes were learning opportunities, publicly

Result: People spoke up. Problems got solved early.

2. Feedback was constant, not annual

– Informal weekly check-ins

– Formal quarterly reviews

– Peer feedback loops

The key: Feedback was about growth, not judgement.

You knew where you stood. You knew how to improve.

3. Hiring for culture fit was non-negotiable

We'd reject technically brilliant candidates if values didn't align.

At the time I thought: "That's excessive."

Now, having seen a company implode from culture mismatch: It was the right thing to do.

What I'm taking from Jaïr's book:

Culture isn't HR fluff. It's operational infrastructure.

Good culture = faster decisions, better retention, compounding trust.

Bad culture = every decision is friction, talent leaves, everything takes longer.

If you're building a startup:

Your first 10 hires set your culture forever.

Optimise for values alignment as much as skill.

What's one culture practice from a previous company you'd bring to your startup?

Advantage: Culture Reflections

Brilliant product vision + aligned co-founders = unstoppable.

Brilliant product vision + misaligned culture = company falls apart.

I learnt this the hard way 🧵

My previous startup had everything on paper:

✓ Strong product vision
✓ Complementary skills
✓ Clear roles
✓ Excited customers

But we had a hidden crack: cultural misalignment between co-founders.

We disagreed on everything beneath the surface:

– How we treat team members

– How we make decisions

– What "transparency" actually means

– Whether we prioritise speed or perfection

– How we handle conflict

These aren't "personality differences." They're foundational.

The product discussions were bearable.

The culture discussions were brutal.

Over time, every operational decision became a proxy war for deeper values we never aligned on.

Here's what I wish I'd known:

Before you write a single line of code, align on:

– What behaviours do we reward?

– What behaviours are non-negotiable?

– How do we give feedback?

– How do we handle mistakes?

– What does "success" mean beyond revenue?

You can pivot a product.

You can't pivot culture once it's set by misaligned founders.

If you're starting a company: Have the uncomfortable culture conversation on day 1.

If you're already running one: It's not too late, but it's harder.

What's one culture value you refuse to compromise on?



Startup Success: Vision vs Culture

How we use Claude Code to maintain consistency across our codebase:

1. Every new feature starts with a markdown spec in /docs

2. Claude reads the spec + existing code patterns

3. It suggests implementation following our conventions

4. We review & work on the implementation

Result: We're moving much faster without compromising on quality.

The trick isn't using AI to write code.
It's using AI to enforce your own standards at scale.

Our codebase stays consistent even as we move fast.

What's your AI workflow for maintaining code quality?

Maintaining consistency across your codebase

Years ago, after doing dozens of product interviews, I stopped asking "What features do you want?"

Started asking: "What would your day look like if this problem was solved?"

The answers completely changed our product direction 🧵

Feature question gets you:
"Dashboard with KPIs"
"Integration with our ERP"
"Better search functionality"

Generic. Uninspiring. Not actionable.

Outcome question gets you:

"I want my engineers to build, not read PDFs all day."

"I want to know we're not missing critical technology trends."

"I want to make decisions based on both internal know-how and external signals."

See the difference?

One describes interfaces. The other describes transformation.

This reframed our entire product thinking:

Less about dashboards. More about outcomes.
Less about features. More about time saved and blind spots eliminated.

If you build B2B tools, try this question in your next customer call:

"What would your day/week/workflow look like if this problem was completely solved?"

The answers might surprise you.

Asking the right questions in user interviews

If you're leading R&D or product development:

What's your biggest "information overload" challenge?

Vote + comment with details if you're comfortable sharing 👇