janmikula
Jan Mikula

Building Nostr for Business protocol.

Public Key

npub1p3hle8dzpmqhtpesfacsh89azfrysw385hgu03fl254ly3k59wnqyp73j7

NIP-05 Address

Profile Code

nprofile1qqsqcmlunk3qast4sucy7ugtnj73y3jg8gn6t5w8c5l422ljgm2zhfspz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dsxmsjdc

Publishing to

relay.damus.io

nos.lol

Author Public Key

npub1p3hle8dzpmqhtpesfacsh89azfrysw385hgu03fl254ly3k59wnqyp73j7

Show more details

Last Notes

2026-04-14 09:14:40 UTC

https://blossom.primal.net/e0fe827ec5be51106768e860bb743f865f0187d745ec79859a668c30c306caec.png
Perfectionism is a red flag
Last post I talked about drilling into unknowns before you build — learning the geology of what you're about to do. Here's the uncomfortable thing that happens when you do that well. You find a lot of problems. And for each one, your brain immediately starts proposing solutions.
If you find yourself convinced there's a perfect one — that's the red flag.
Perfectionism isn't about quality. It's about psychology. It's your brain protecting itself from a hard truth. Every solution is a trade-off. Choosing one means accepting that from some angle, it's not ideal. That's uncomfortable. That's the weight you have to carry as a builder. And perfectionism is just a way to avoid picking it up.
Before our daughter was born, my wife and I read everything — or so we thought. We'd gone deep on sleep, feeding, emotional development. We had the night sleep routine figured out before she even arrived. Then she arrived and we discovered how daily naps reshape your entire day — how every trip, every plan has to bend around them, how much logistics goes into something we hadn't even thought about. We completely missed that side of sleeping. And that's just one example. As she grew, so did we. We started seeing things as they are — options where none of them was perfect, but as parents we had to make quick decisions in the given situation, own the consequences, and do it again and again.
That's exactly what good product decisions feel like.
There's a saying — perfect is the enemy of good. Most people interpret it as a time problem. Finding the perfect solution just takes too long. I don't think it ever was about time. And with AI today, it definitely isn't — you can explore ten alternatives before lunch and build something that looks perfect faster than ever. But that's exactly the trap. If you're using AI to always polish one more thing on your perfect idea, it only pulls you deeper into the rabbit hole and keeps you from seeing reality clearly.
The problem is that perfect solutions don't exist. Building toward one is your brain pretending the trade-offs aren't real. And it's not just trade-offs. It's risks and unknowns too. Every solution has things that could go wrong, things you don't fully understand yet. The perfectionist brain doesn't want to see them — because seeing them means admitting you're about to make an imperfect decision under uncertainty. But that's always the situation. Pretending otherwise doesn't reduce the risk. It just means you stopped looking for it.
See things as they are. Choose the right trade-offs. Accept the risk of being wrong. Own it.
Don't chase perfection. Be the product leader who sees reality clearly — and builds what matters, not what's "perfect".
This is post 4/8 from my talk at Dev/Hack/Day, @nprofile…py4c 2025.

2026-04-08 14:23:55 UTC

https://blossom.primal.net/cb3b425f6ca8fc3fea4e0902d4f0344bac071d65581e29d4f0242febcdb6307a.png
Before you build, drill (I meant prototype)
Last two posts I talked about understanding what customers need to fire and hire — and how to get the real story out of them. But knowing why to build something is one thing. Figuring out what to build is another quest entirely.
Most teams follow an agile process that's really just waterfall happening faster. PRD → Figma → tickets → code → test. People say we're in a new era with AI now. Honestly? This was already true 10 years ago. I know, because that's why I switched from frontend engineering to product. Writing code wasn't the hard part. Making the right decisions was — and we kept getting that late or wrong.
A side hobby of mine — I followed how highways are built in my country. Before a highway gets built, highway builders do something called geological exploration. They drill holes along the entire route — not to build the road, but to understand what's underneath. If there's a tunnel planned, they'll actually drill a small pilot tunnel first. Not to "build" the tunnel. To learn what the mountain is made of, so they can design the real one to last.
That's what prototyping should be.
Not a rough draft of the product. Not a "quick and dirty" version you'll clean up later. A deliberate investigation into the areas where you have the most unknowns.
Prototyping is learning. Prototyping is de-risking. Prototyping is understanding complexity so you can make decisions about it.
In product work, your "geology" could be anything. Maybe you're an early-stage startup and you don't know if anyone actually wants your idea. Maybe you want to use a library you've never used before. Maybe you have a huge customer base and you're about to introduce a controversial feature with no idea how they'll respond.
Each unknown needs a different kind of drill. But the principle is always the same: go deep where the risk is highest, before you pour concrete.
Yes, AI gives you a faster, more powerful drill. And honestly, it's incredible — working with AI makes me so much better as a PM and it's also way more fun. But a faster drill doesn't mean you don't need to understand the unknowns and the hidden complexity. You do.
Don't jump from idea to building. Drill and learn geology first. I meant prototype.
Thanks to Ryan Singer for inspiration on this one.
This is post 3/8 from my talk at Dev/Hack/Day, @nprofile…py4c 2025.

2026-04-02 12:31:42 UTC

https://blossom.primal.net/32b6f82decada91a27b43e83f757f3263cb846a8bf64c5575a96529d3d601cfa.png
During customer interviews, you're a detective, not a podcast host
Last post I talked about what customers have to fire before they can hire your product. But knowing that is only half of it — you still need to get the story out of them.
Most customer interviews sound like a friendly podcast. Open-ended questions. Lots of nodding. "What features would you like to see?" "How would you improve the experience?"
That's collecting opinions. And opinions are noise.
When someone tells you "I think it would be great if your app had X" — that's their imagination talking. It tells you almost nothing about what they'll actually do.
What matters is what already happened.
As kid I watched Detective Columbo. Every episode was this dance between Columbo and the suspect. The suspect would spin this fog of opinions, explanations, alibis. Columbo ignored all of it. He just kept nitpicking the details — what happened, when, in what order — until the real story unraveled on its own.
That's the mindset. Your customers aren't suspects — they're not lying to you on purpose. But they'll give you the same mix of opinions, rationalizations, and wish lists. Your job is to stay focused on what actually happened.
The question you should ask most often is "when" — closely followed by "why."
My favorite opening: "When did you sign up for our product? Why didn't it happen the day before — or the day after?"
My favorite follow-up: "Can you tell me more? What does that mean?"
Those questions force people to stop generating opinions and start remembering what actually happened.
Pay attention to where the energy shifts. When a customer gets frustrated, or suddenly specific — that's the signal you've hit something real. Like the end of a Columbo episode, when all the nitpicked details suddenly click and you see exactly how the crime happened. That's the moment you understand the full switch — from the old solution to yours.
Stop collecting opinions. Start reconstructing timelines and motives.
Thanks to Bob Moesta for the inspiration on this one as well!
This is post 2/8 from my talk at Dev/Hack/Day, @nprofile…py4c 2025.

2026-03-31 06:54:46 UTC

What a customer has to fire, so they can hire your solution
Everyone says "start with the problem, not the solution." Honestly? That's not great advice.
People don't think in problems. They think in solutions. When you're hungry, you don't sit there contemplating hunger. You're already imagining a burger or a pizza.
When you're building a product, yes — you need to understand the problem. But that's not enough. You need to know how people are solving it right now. Because that's what they'll compare you to.
If you want people to use your solution, they first have to stop using something else. It could be anything. Sure, sometimes it's your direct competitor. Often it's the spreadsheet they're duct-taping together. The pen and paper they're scribbling on. Sometimes it's just the mental note they've been keeping in their head.
Before someone can hire your product, they have to fire something. And that's hard. They're comfortable with what they have. They know its quirks. They've built habits around it. That's what's working against you.
But they also hate certain things about it — and something about your product caught their attention. That's what's working for you.
If you understand both sides — what's pulling them back and what's pulling them forward — you can figure out how to make the switch easier.
To uncover this, ask your recent customers three simple questions:
🔹 What were you using before us?
🔹 Why did you fire it — and why did our product catch your eye?
🔹 When did it happen? What was the trigger — the last straw?
That third question is the real unlock. It reveals the trigger moment — the thing that turned a vague frustration into action.
Don't start with the problem. Start with the solution that needs to be fired — that's how your product or feature gets hired.
Thanks to Bob Moesta for the inspiration on this one!
This is post 1/8 from my talk at Dev/Hack/Day, @nprofile…py4c 2025
https://blossom.primal.net/3cfb6363d3daf14d1227fa87b55eb52a4c19ec3f50bca120aaa64ddc83db2666.png

2025-01-13 09:18:38 UTC

- reply

I want that too!

2025-01-02 18:13:14 UTC

- reply

@nprofile…cps4 is this nice use case for Evolu?

2024-12-27 14:57:22 UTC

- reply

Yeah, I've been burnt many times...

2024-12-27 14:39:34 UTC

- reply

If the Nostr for Business will take off, I would definitely pitch it to them!

2024-12-27 08:27:12 UTC

- reply

They are pretty against oligopolies and closed systems, so I think there is a good chance that they will get Nostr. Honestly, their product Once.com played major inspiration in the Nostr for Business idea.

2024-12-23 18:21:39 UTC

- reply

Left you a DM.

2024-12-23 15:09:12 UTC

- reply

Do you see any crossovers of Nostr for Business and the projects you are working? Trying to put together people that might contribute in shaping this vision...

2024-12-23 15:03:02 UTC

- reply

In my defense, this was the WIP version. I planned to redraw it to make it bit more readable. But then people asked me to publish it.
I will probably redraw it a bit and then publish it natively on Nostr. But don't expect miracles. I can't draw very well. 🤣
On serious note. I will DM you, I would love to talk with somebody with security and Saas experience.

2024-12-23 15:00:06 UTC

- reply

I would be curious about that as well!

2024-12-23 14:57:22 UTC

- reply

PowerPoint on my Surface Laptop Studio.

2024-12-21 21:10:58 UTC

- reply

Pssst! That's in notes for the funding pitch. 🤣
In all seriousness. That's one of our priority and reason why we are so excited. This will allow completely new experiences that will be very hard to match for traditional SaaS apps.
One example that I really like. Figjam <> Notion integration where block in Notion can be placed in the Figjam whiteboars and be automatically synced. Typically when you organizing some workshop and you have brief document. That document can live in Notion, in Figjam board and the even shared in Slack. Whenever you change something, it will change everywhere.

2024-12-21 16:03:20 UTC

- reply

2024-12-21 08:04:30 UTC

- reply

Yeah, I read the whole book the day it was published. It had huge influence on my thinking.

2024-12-20 21:37:05 UTC

- reply

Great, I will DM you.

2024-12-20 21:36:04 UTC

- reply

Awesome. I will DM you.

2024-12-20 21:35:11 UTC

- reply

Please give me feedback and want to hear your thoughts!

2024-12-20 20:47:20 UTC

- reply

In my defense, I haven't planned to share it today. I was just getting feedback on @npub1jea…wcny open hours and people there asked me to share it publicly. 😉

2024-12-20 20:27:20 UTC

- reply

When you look at current SaaS apps and how you integrate with each other. You recognize that Slack is in the middle of it. All other apps have some kind of integration with Slack. That's also a reason why so many people hate Slack and the same time it's really hard to build competing product. Because they have very strong network effect that locks you in.
But with Nostr we have a way how to break such lock by offering open protocol that is easy to integrate with.

2024-12-20 19:52:48 UTC

- reply

Don't have a preference. Will leave it up to the engineers who join us to determine what's the best stack for it.

2024-12-20 19:49:47 UTC

- reply

No timeline. We spent last 3 months working in this as side project with my old colleague product designer. We wanted to clarify our vision. Plus we have some early concepts for building great alternative to Slack.
Today, I wanted to validate with Nostr community that the idea makes sense and is doable. Seems it is. Now I want to put together team with engineers and starý building this.

2024-12-20 19:43:15 UTC

- reply

Absolutely. Let's connect! I'm finding ways how to make this happen.

2024-12-20 19:42:11 UTC

- reply

💯 Completely agree with you.
The reason why I'm so excited is that Nostr can bring next level of experiences and data security +ownership.
So I thing there is real chance to beat the legacy apps.

2024-12-20 19:35:43 UTC

- reply

That's awesome. I will DM you and we can have a chat.
BTW I've just joined @npub1jea…wcny on HiveTalk and it worked like a charm. Great job!

2024-12-20 19:33:30 UTC

- reply

That's another reason why we want to rebuild Slack. Everyone hates Slack. Me as well. It's design in such a horrible way.
We have some cool ideas to make it way better, so people feel it helps them being productive opposed to being constantly distracted how Slack does it.

2024-12-20 19:31:06 UTC

- reply

My background is product strategy and I'm teaming up with my old colleague product designer. So, we are looking for engineers to help us build this.

2024-12-20 19:29:27 UTC

- reply

Our initial thinking is to build alternative to Slack, because if you look at current SAAS apps, basically all of them are connected to Slack. It's the brain. My instinct is that if we can build great alternative to Slack, everything else will follow.

2024-12-20 19:17:49 UTC

- reply

Thanks for the tip. I will add it to my list of apps that we should pitch or directly help to integrate with Nostr for Business.

2024-12-20 19:16:27 UTC

- reply

Haha. Sorry. 🤣
Yeah, this needs to happen. When we were playing with the Figma prototypes, we were so excited since it feels so natural and improving the experience of current SaaS apps.

2024-12-20 18:24:08 UTC

- reply

Unfortunately no, it's all drawn in a hand.

2024-12-20 18:03:40 UTC

- reply

Is it similar?

2024-12-20 17:52:32 UTC

- reply

Awesome. I DMed you!

2024-12-20 17:11:22 UTC

We are working on an idea how to build SAAS business apps on top of Nostr. The idea is to rebuild apps like Slack, Notion, Figma, Github, Linear on single Nostr relay and Nostr standard that would allow some cool things like seamless cross-app messaging (e.g. like Slack <> Linear), cross-app workflows.
Here is PDF with more details.: https://drive.google.com/file/d/1U_bC4AmR2_61GwgiShNv_EctOcyh4u7A/view?usp=drive_link
If anybody is working on something similar or like the idea and want to join our efforts, please let me know.

2024-12-20 08:09:23 UTC

- reply

Totally agree! Interoperability is such a important thing. You've seen my Nostr for Business deck and one huge inspiration to start working on it was the fact that all SAAS business apps like Slack, Notion,... are trying to be this huge superapp. The problem is that the experience is getting worse as they are adding more and more features.
Having small dedicated apps that are exceling in the small niche and are seamlessly interoperable with other apps is the way to go.

2024-12-19 15:27:31 UTC

- reply

That's great! Is there any write up or specification that you guys worked at specifically around the work set of tools? I'm planning to explore this direction of Nostr...

2024-12-19 07:58:20 UTC

- reply

Hey William, last couple of months I've been doodling with similar ideas. I call it Nostr for Business and the idea is to rebuild apps like Slack, Notion, Github, Linear on Nostr standard which would enable great experiences like:
1) Cross-app communication - it wouldn't matter if you're responding from Slack, or GitHub PR, it would be the same thread.
2) Cross-app workflows - e.g. close ticket directly from Slack thread where the ticket is mentioned.
3) Cross-app components - that's exactly what you're mentioning in your post.
Can I send you DM with the PDF and Figma prototype? I would love to hear your thoughts on this. https://m.primal.net/NAWa.png https://m.primal.net/NAWc.png

2023-09-06 07:52:24 UTC

Suffering with too many WIP never-ending projects? Here is what 37signals recommend:
— You need to focus on finishing WIP projects first. You can’t add new stuff unless the previous stuff is finished.
— Being 90% done could mean that you're still only halfway through the project.
— Don't work on two things at once. It's a huge mental burden.
— You need to focus on hard issues first and don't start with easy ones and wait until the end for the hard ones.
— Giving lots of time to a project is a curse, not a blessing.
https://youtu.be/vnAWT06Bsgw?si=kyInX6uv-9ZC-9EX

2023-09-05 06:21:16 UTC

This season on the Rework podcast (by Basecamp) they are discussing many "chapters" from Shape Up. In this episode they discuss Writing a Pitch.
Few insights:
— Writing a Pitch is not the same as shaping. Writing a Pitch is just formalizing the shaping discussion.
— Try to find a balance between writing a detailed spec and having just one line.
— The goal is to give teams of two (designer + engineer) a sense of autonomy, purpose, and mastery.
— Most of the design decisions are made during the cycle since, according to them, that's the most effective way.
— The pitch should focus on Rabbit Holes to identify risks and things that could take forever.
— When you feel that the whole Pitch is one big Rabbit Hole, treat it as a science project with the goal of getting information.
https://youtu.be/d_a-Jojd3Pc?si=OK5BgSuO4jve32UD

2023-08-30 12:21:57 UTC

New version of Swan App is rolling out.
What's new?
— You can finally initiate withdrawals directly from the app.
— If you like to buy dips, turn on notification for bigger price movements.
If you're Swan customer, please don't hesitate to share your feedback!
https://void.cat/d/GQCzJA2EVNqfCGEtLfPH22.webp

2023-08-23 19:08:04 UTC

- reply

Can't wait to read this book!
#nevent1q…94pr

2023-08-02 07:16:32 UTC

- reply

It works in a way that on each table in restaurant there is a QR code and you scan it and you can order things and also pay for the order with your phone. And one payment option is newly LN.

2023-08-01 15:05:07 UTC

- reply

To by se mohlo v dohledné době změnit. https://9to5mac.com/2023/02/07/new-iphone-browsers/

2023-07-29 12:29:01 UTC

- reply

Teď už vidím splash screen. Ale stále se to neloaduje. https://nostrcheck.me/media/public/nostrcheck.me_1799875340249943261690633716.webp

2023-07-29 10:38:45 UTC

- reply

Nefunguje mi v Edge mobile browseru na Androidu. Vidím jen černou obrazovku.
Věřím, že mouchy brzo vychytâte. Jinak super práce s PWA. https://nostrcheck.me/media/public/nostrcheck.me_6487286204442277701690627022.webp

2023-05-24 11:22:30 UTC

- reply

Yep, I have lots of similar views as Dergigi.

2023-05-20 18:46:40 UTC

- reply

I see 3 types of Persona's on social media. Content creators producing unique content. "Editors" that are retweeting or reposting with comments good content from Content creators. Consumers who read, watch, and listen good content.
I always wanted to build a product that would allow Editors curate the best content for their followers, get money from subscription, and give fair share from subscription to Content creators which their content has been curated by the Editor.
In other words, we have so much content that I would like to pay somebody to curate my content and that person would give some portion of that money to people that produce high quality content.
And I think Nostr will allow that.

2023-05-20 18:39:54 UTC

- reply

If I understand the V4V concept, it's more like tipping after you reading the post.
I like subscription model since it gives content creators more predictibility in revenues and more thighs to their readers.
The problem with current subscription model is that platforms are closed and not interoperable. Generic subscription model like Substack over open interoperable protocol like Nostr can create new options and business models for content creators.

2023-05-20 06:11:07 UTC

- reply

Very nice update!

2023-03-02 20:54:36 UTC

Paywall app like Substack over Nostr makes lots of sense to me.

2023-03-02 19:16:05 UTC

Is there a way to create a subscription model using LN payments over Nostr?
In other words, how can you distribute content behind a paywall that people can only access if they prove they paid for it with LN?
Is somebody exploring this?