DEV Community: Steven Borrie

The mistaken assumption of software startups

Steven Borrie — Wed, 22 Nov 2023 05:53:49 +0000

We all know that most startups must fail. But after working on many different projects, it surprised me that many seemed to struggle because of essentially the same problem - they underestimated the difficulty of acquiring users.

Building a product is just the first step, so here is some of my advice to deal with the real challenge of attracting and retaining users.

Balance confidence with scepticism

As a startup founder, you'll spend a lot of time talking about your ideas. While pitching confidently is essential for inspiring teams and attracting investors, it is important to balance confidence with scepticism in the planning of your product. When you're building your product, you have to ensure that you test your ideas.

Don't let your confidence become dogmatic over-confidence. Until you've actually shipped anything, it's not a done deal - you don't have any users yet.

You're probably working on your product because you're excited about it. You may be surprised by the indifference of your potential users - even if your product is objectively better than what they currently use, they may not care enough about the advantages to make the switch.

Until you've acquired users who have begun to rely on your product, you are the one who cares the most about it, and all your potential users care less than you do.

Don't build too much in one go

Most ideas can be built, it just takes time. The more features you include, the longer it will take. The longer it takes, the more it costs.

If you have too much confidence in your idea, and in your ability to acquire users, you might conclude that you may as well build all your features now. After all, why bother having multiple releases if you're going to have tons of users as soon as you announce your completed product to the world?

But that's not how it works. If you don't release and test your first features with real users immediately, you're robbing yourself of essential feedback.

If your product is not complete enough to convince anyone to pay for it yet, give it to your test users for free, or you can even pay them to use it.

Gather facts in your user research

You can actually pay your potential users for information before you've built anything at all, but make sure you focus on the facts.

If you ask your potential users whether they would find your product or feature idea useful, you'll get misled by the number that say "yes" when they are really a "no".

They don't mean to mislead you, some might say "yes" out of politeness, but it's mostly because they can't predict their own behaviour until they actually try using it.

Instead, it is better not to put too much weight on these subjective questions and to ask your potential users things that are much easier for them to answer - simple facts. You can ask them how many times in the past year they've experienced the problem that your product solves, or how much money they spend on similar products.

Measure impact as well as value

Solving a real problem is important, but impact matters equally.

This is a bit like Bayes' Theorem - having a brilliant solution to a problem doesn't matter much if very few of your potential users ever experience that problem, or if they only experience it infrequently.

This applies to feedback too. If 80% of your users tell you they need a new feature, but it is the other 20% that account for most of your usage, it may be more worthwhile to make small improvements that only 20% want, instead of building new features that 80% want.

Avoid feature overload

The mentality of continuously adding features in the hope of attracting users can lead to product bloat.

Don't assume that your struggle to acquire users is because you haven't got enough features yet, and set about adding more features that no-one will ever use.

If you're testing your features ~~early~~ immediately, you'll already know which ones are useful. Consider deleting the ones that aren't before letting your product get bloated. Quality trumps quantity.

Conclusion

The path to building a successful product requires much more scepticism and adapting to feedback than you might expect. Hopefully by following these principles you will increase your chances of building not just a software product, but a thriving user base.

Building my portfolio blog with Dev.to and Next.js

Steven Borrie — Thu, 11 May 2023 07:47:46 +0000

Check out my website here: stevenborrie.com

Previously I had experimented with tools like nextra, however I was unhappy with the lack of simplicity, and the default themes.

Dev.to API

Turns out, the dev.to API is incredibly simple. You can give it a try:

JSON array of all my posts: https://dev.to/api/articles?username=saborrie
This post: https://dev.to/api/articles/saborrie/building-my-portfolio-blog-with-devto-and-nextjs-268f

I realised I can just put all my posts on dev.to, and use it as a CMS database for my website.

Building my blog in Next.js

All I wanted to create was 2 pages: a home page, and a blog post page. The home page would be at / and the blog page at /post/[slug]. On the home page, I wanted to show a list of links to all of my blog posts, and on the blog post page, I wanted to show the content based on the [slug] parameter in the URL.

After setting up my project using yarn create next-app selecting typescript and the new app router, I added the following code to the homepage in src/app/page.tsx:

import Link from "next/link";

export default async function Home() {
  const posts = await fetch("https://dev.to/api/articles?username=saborrie", {
    next: { revalidate: 10 },
  }).then((x) => x.json());

  return (
    <main>
      <h2>Posts</h2>
      {posts.map(({ slug, title, description }: any) => (
        <Link href={`/post/${slug}`} className="post-list-item">
          <h3>{title}</h3>
          <small>{description}</small>
        </Link>
      ))}
    </main>
  );
}

The new app router supports server side fetching by making your page components an async function. By default, Next.js will cache the results of the fetch at build time. We can configure the fetch to rerun during server rendering by setting the revalidate setting - I've set it to revalidate every 10 seconds in the code above.

To create the blog post page at /post/[slug] I added the file src/app/post/[slug]/page.tsx. Using the following code I am able to write out the title, cover_image, url, and body_html from the dev.to API:

export default async function Post({ params }: any) {
  const post = await fetch(`https://dev.to/api/articles/francescoxx/${params.slug}`, {
    next: { revalidate: 10 },
  }).then((x) => x.json());

  return (
    <div className="post">
      <img title="cover image" className="cover-image" src={post.cover_image} />
      <main>
        <h1>{post.title}</h1>
        <small>
          <a href={post.url}>View on dev.to</a>
        </small>
        <div dangerouslySetInnerHTML={{ __html: String(post.body_html) }} />
      </main>
    </div>
  );
}

This worked great, except that I needed to do some work to get syntax highlighting in the code snippets. As dev.to is open source you can just go get the scss file at https://github.com/forem/forem/blob/main/app/assets/stylesheets/components/syntax.scss. To import scss in Next.js you need to run yarn add sass. And that's it, it worked. I was then able to copy my existing css from my old nextra portfolio in and I was done.