• IdeaHub
  • Posts
  • 🧠 3 SaaS ideas for the rest of 2023

🧠 3 SaaS ideas for the rest of 2023

An API testing platform, a project estimation tool and AI website generation...

H1 has been and gone! It’s been a bit of a whirlwind for tech in general with mass layoffs continuing, VC funding drying up and AI continuing to take over the internet as expected…

There’s still plenty of opportunity for budding entrepreneurs, and with a slew of highly talented tech peeps hitting the open job market, we may look back on this period and see that many great companies were founded out of the dust.

Today we’re taking a look at 3 new product ideas that I’ve been analysing over the last few months. I’ll take you through the competitors I’ve looked at, what I think would make a good MVP and how difficult the products would be to get to market successfully.

Here’s a breakdown if you want to get straight to it:

  1. An API testing platform that doesn’t suck…

  2. Solving project estimation

  3. AI = end of web development?

Otherwise, let’s jump in…

1. An API testing platform that doesn’t suck…

The Problem

As codebases grow it can be easy for testing to get left behind as urgency drives iteration without proper consideration. In my opinion, this is made worse by inadequate tools that slow down the API testing process.

Anyone that’s tested an API before has likely come across the largest incumbent, Postman. Firstly, Postman is great at a lot of things like documentation, mocking and API monitoring. However, it’s in testing that I think there’s a lot of value left on the table.

The following example demonstrates this clearly. Say you build a new API with 2 query parameters - pretty normal stuff. Well, in order to test the different combinations of those parameters, you would have to duplicate that request 4 times and enter the combinations manually! There’s no way to simply define the blueprint of the request and then customise it in each of your test cases. Duplicating stuff is never good in development and here is no exception.

Insomnia is another younger, but rapidly growing API development platform. Acquired by Kong in 2019, this is the classic open-source challenger play to platforms like Postman that essentially try to cover all of Postman’s core features (albeit not quite there yet…) and build in native integrations with Kong’s other API-focused products like API Studio. The testing experience is better than Postman in some ways as they do allow developers to test multiple cases against one request - but it still won’t let you customise the blueprint of the request for each test case.

API testing tools

Postman (left) and Insomnia (right)


For me, the MVP of solving this problem would be a simple way of defining a request ‘blueprint’, similar to Postman, including all the various query parameters, authorization, headers & cookies etc. But then there would need to be another area of the platform, ‘Test Suites’ perhaps, where a developer could choose a request, set up the query parameters and headers etc for that specific test and then write the assertions in code. This would mean no duplication at all and that writing new tests would be just as it should be - extending what’s already there.

I think having testing in a separate area of the platform would help it feel more dedicated; at the moment Postman’s testing features are a little hidden away. I know for a fact that plenty of developers who use Postman have never even touched the testing features.

As with all MVPs, I’d forget about supporting sign-ups for now and just create accounts for my beta users to begin with. I’ve found it saves heaps of time building what can be one of the most intensive parts of any software product.

To find some initial users, I’d initially target developers as those are going to be the bulk of the market here. Luckily, Insomnia being open-source gives us plenty of data on who exactly would be interested in a product like this. I’d reach out to the posters of open pull requests and issues on Insomnia’s GitHub page, starting with those that look like new feature requests.

And of course, I’d post on the official IdeaHub Reddit community to gather feedback and maybe find some more beta users.


This could be bootstrapped as I think it is possible to build the MVP with a small, focused team. Reaching feature parity with something like Postman, however, would require considerable effort and likely involve some outside money, although that would be way down the road anyway if an MVP proved successful.

There’s tonnes more value to pull out here in terms of source control, CI integration, test data management and multi-step testing but far too much for one post, so I might explore this more in a dedicated post.

2. Solving project estimation

The Problem

“How long is a piece of string” - that’s something I heard a lot across the office when I worked in software consultancy. Customers always want to know, to the penny, what their costs will be for their new shiny website or mobile app. And rightly so - everyone has a budget!

The answer to this question was always “We’ll have to go away and come up with an estimate for you”. Again makes sense, setting expectations is a key part of the consultancy business. So internally the project lead would go away and put some numbers together, usually in a spreadsheet (*shivers*), with some custom calculations on day rates and tack on a few extra days for contingency.

Now in truth, like all processes, it works fine until it doesn’t. Underestimation is the top killer of fixed-price software projects. There are plenty of valid reasons for projects going over budget - requirements are evolving beasts only tamed by the most experienced project managers!

But I’ve also seen my fair share of just plain incorrect estimates throwing spanners into the works. To discover this you have to understand what is involved in getting to that bottom line figure.

Often a project can involve multiple different disciplines, maybe web development and mobile development. This means project leads can take it upon themselves to go out and conduct an interview with the tech leads to decide upon the correct figures - a lot of work. I’ve also seen tech leads come up with the numbers themselves, often using different calculations, and then the project leads try to figure out how it all fits together - no thanks!

Whatever the process, it’s error-prone. People using different spreadsheets with different assumptions, and not communicating the true scope of the project ultimately run the risk of missing tasks altogether.

In the end, customers are disappointed as projects run longer than expected, and agencies lose out on revenue as customers hold them to account for their estimates.

Again, there’s heaps of extra value I could talk about so there might be another post incoming!


To put it simply, a platform that provides a way of creating and managing estimates across different clients. A platform that makes entering and adjusting estimates against different tasks as simple as if in a spreadsheet, but allows the configuration of calculations in a more opinionated way, specifically applying this to the maintenance of day rates and contingency factors.

I would put a specific focus on restricting who could change calculations and providing templates that estimators from every team can start from with the business’s own numbers and calculations baked in.

Collaboration would also be important to start conversations and to allow estimators to discover areas they might have missed that others have thought of.

I would then include some basic PDF generation to get this data into a branded proposal that a user could send off to their customers from the platform itself.

There are multiple ways to approach this problem; either by building a plugin to an existing work management tool already used by agencies, or by building out a standalone platform that could integrate with other work management systems further down the line.

Some comminly used PM platforms

Jira (left) and Monday.com (right) are both common in agencies

Both have their own unique advantages. By building on top of a platform like Jira, you gain access to their customers and can advertise directly to them in the app marketplace. However, app marketplaces are crowded with high-quality apps making up the minority which can make it a hard sell. Additionally, you lock yourself into a particular platform which poses risks longer term as you tie your success to theirs.

Building your own dedicated platform takes away that risk - you get to own it and decide everything from the UI right through to the pricing model. However, this will involve more work upfront and it could be more difficult to find those initial users.

The most similar solution is Simple Estimate, which is a single developer-built tool for agencies with calculations, templates, and some basic sharing capabilities.

An interesting contender is SocraticWorks which is an all-in-one work management newcomer alternative to the likes of Jira etc that also has some neat estimation tools. I particularly like how they use Monte Carlo to estimate the time required for tasks from your existing data. It would be interesting to see a platform use generative AI to give you at least a starting point for estimates too.


I think this is a very accessible problem for anyone with some coding skills but good knowledge of the agency process and business model would be a definite advantage to knowing the direction to take the product longer term. I also think this shows in the existing solutions which is great validation.

No need for raising money here, and even if you wanted to I think it would be difficult and small this sort of thing isn’t really in the wheelhouse of VC or angels.

I guess my experience puts me firmly in the realms of being able to tackle this problem so perhaps it’s something I’ll find myself working on sometime soon…

3. AI = end of web development?

The Problem

I’m particularly excited about this idea as various GPTs and CoPilots have shown how well they can generate functional code. We’re already starting to see some specific applications of this new technology to website building including Durable, Hocoos and many…many…MANY more.

These are all essentially trying to solve the core problem for all technology companies - developers are expensive! The fewer lines of code a business can write and therefore own, the fewer developers they need thus lowering their fixed costs.

Just replacing these expensive nerds (it’s ok, I’m one of them…) sounds like a great solution but in reality, there’s a lot more work that goes into web development than just writing code. You still need to know what to build, for who and when.

Current Web Development Model

Developers write code that is seen by all customers

That’s where I think there’s a lot of value to be had in AI driving this process too. We live in an age where our entire personal psyche lives within databases so why can’t ALL the content we see online be driven by this data? No not just the specific results we see on Google or the posts we see on Instagram, but the ENTIRE content.

You and I respond uniquely to different colours, images and specific layouts or words based on our personal experiences - it makes sense therefore that the websites we visit have content dictated by this data.

Web develpment using AI

AI could decide what a website should look like

In a new model of web development, a business would collect customer data and feed that to a model trained on that data to generate HTML + JS code on a server before a user requests a page.

The obvious applications of this are most likely to be on landing pages and similar promotional pages where there is a specific intent for the user the AI model could optimise for like a signup or a click of a button.


Luckily for us, the last 4 decades of web development have already given us most of the tools we need here. SSR (server-side rendering) is already a key component of most modern websites nowadays and storing customer information is already a solved problem.

An AI model, on the other hand, is a little bit different… I’m no AI expert but looking at the tools available in the market today I’d say there’s work to do to get to a place where an entire web page could be reliably driven by AI according to branding guidelines, customer attention data and business KPIs.

A starting point, however, could be to start from a foundational model based on a GPT and train it on your existing Google Analytics (or similar platform) data. You could then hook this up to a server-side process to serve the HTML + JS to the browser.


I hate to say it but I think this is one for the big dogs…the skills required, particularly in the AI space, to get this reliable enough to draw meaningful value from is definitely going to need considerable funding.

I guess after all we are talking about an entirely new way of doing web development, so I suppose it’s justified!

But who knows, maybe you have the perfect skills to tackle this yourself! If you know of a better way to solve this problem I’d love to hear it - post on the official IdeaHub Reddit community and we can all discuss.


There we have it, hopefully, the ideas I’ve shown will provide some snippets that you can take away and apply to your own idea-generation process or just trigger some thoughts that help you out with whatever problem you might be facing on your current projects.

If you want to get more ideas like this to your inbox every week then make sure you sign up for the email newsletter here.

Join the conversation

or to participate.