Blog

<h2>Software is more than just features</h2>Over the last 10 years, I have seen a shift in SaaS start-ups and scale-ups in their software development approach. 20 years ago, waterfall methodologies were king, and a lot of time and effort was spent on analysis and on understanding how a software product was built, brick by brick. Possibly due to the rise of Agile, a number of software companies have shifted from building coherent software to just building features. This is especially true in environments where business leadership is more vocal than technical leadership. This isn't an issue with Agile itself, but with how it is often implemented in these organisations.<h3>Why is that wrong?</h3>The problem is that software is so much more than a set of features. Those features need to work well together, form part of the user experience, and follow a coherent path. Without a plan, everything starts to quickly fall apart. Some businesses also like experimentation and might set aside funding for a proof of concept or a quick trial product. There too, a plan is critical, so that you can bring that POC or trial back into the core product - or at least the concepts they were trying to demonstrate. Too often, those experiments are left unattended, and 6 months later, no one remembers them in detail. The core product has evolved too much, and there are no options but to restart those projects from scratch. Building revenue-generating features quickly, without a plan to address technical debt, can be tempting, especially in environments where the business pressure to deliver quickly is high. But remember, your product needs to scale in line with your business goals. There is no point in having spent all that time, effort and money on building a product if it fails as soon as you land that large deal. Not only will you have to rebuild a lot, but you'll also have to recover from the reputational impact. Finding the right balance is very difficult, and that is where we help our customers understand the compromise and make the decisions which are right for their specific business circumstances.<h3>The straw bridge</h3>Pictures speak louder than words, so to use an analogy: Imagine you're a SaaS founder and asking your tech team to keep building features. They built you an amazing-looking bridge. Your current volume is low, but the couple of cars using that bridge every month love it! Your sales team worked hard on building momentum, and you have a highway full of cars ready to start using the bridge. You feel you are ready to open the flood gates, except... the bridge is built of straws!!! It does perform very well for the couple of cars using it currently, but it will come crashing down very quickly as more cars start entering the bridge. <figure id="figure-ns7qrbgc8gmls48ir7"><img id="ns7qrbgc8gmls48ir7" src="https://cdn.durable.co/covers/25vcnkc5Yd1LHqP6pL0ImVMnNJPxU33tzhD52qVBcKW2WwB4Fj5CETKDhTnJEqNX.png" alt="" title="" class="object-cover bg-gray-100 rounded-lg md:rounded-xl lg:rounded-2xl" style="aspect-ratio: 16/9; object-position: center center;" data-corners="default" data-aspect="16:9" data-caption="" data-positionx="undefined" data-positiony="undefined" data-fullwidth="false" data-mce-src="https://cdn.durable.co/covers/25vcnkc5Yd1LHqP6pL0ImVMnNJPxU33tzhD52qVBcKW2WwB4Fj5CETKDhTnJEqNX.png" data-mce-style="aspect-ratio: 16/9; object-position: center center;"></figure> This is the situation I have seen time and time again in a number of businesses we have been helping. Usually, the first answer from founders is: "I don't mind the bridge being improved; for now, I need to focus my limited funds on building an extra lane so I can charge more and generate more revenue!" Obviously, this isn't the correct answer for the business, and that is why understanding the situation and the return on investment on each 'feature request' is critical.If you need help digging into this in more details your business today, we’d be very happy to help. Click <a data-mce-href="https://aldemis.com/contact" href="https://aldemis.com/contact">here</a> to contact us.

Software is more than just features

<h2>What value does AI truly deliver?</h2>I may have spent the last 10 years on the business side of things — after an early career as a technologist building stock exchanges and trading platforms, followed by a move into tech advisory — but those who know me will tell you I'm still very much a geek at heart. It's this dual experience of building technology, and more recently being a customer of technology, that helps Aldemis bridge the gap for our customers… but this isn’t a sales pitch.As a geek who still loves coding, I've followed the AI coding movement closely. While there have been some impressive advances, for me the proof is in the pudding. Until a real application is built, released, and used, it's hard to draw meaningful conclusions about the actual benefits of using AI. In the vein of one of my favourite sayings: ‘I could get my mom to build you a Windows calculator, it would look like it is working, but it wouldn’t be scalable, secured, or anywhere close to being maintainable!That's why I decided to take my latest idea and build it entirely with AI. The website below is the result — built using Claude Code (Opus 4.6) on the Max Plan. I've also pasted below every prompt I used along the way.I did nothing beyond writing the prompts listed below (less than 100 prompts in total). I didn't modify the code by hand. I didn't touch a single thing outside of the Claude window itself *.The whole thing took me roughly 9 hours from start to finish (though most of that was waiting for Claude to do its thing, so I was getting on with other tasks in the meantime). If I'd done this the traditional way, I estimate it would have taken around 8-10 days.Here's what I find particularly interesting: if you look through my prompts, fewer than 5% of them are actual technical requirements. Everything else is business requirements.&nbsp;The website and code are by no means perfect, but the result given the effort involved is genuinely remarkable. Some prompts felt especially easy such as 'deploy to AWS' and... job done! Or 'containerise everything'.This was a greenfield build, which is always easier for AI to handle. That said, I have used Claude on an existing project too, and I have no reason to think the results would be dramatically different.I feel like I've only scratched the surface of what's possible. One of my colleagues even took a screenshot of our JIRA board and had Claude implement all the tickets assigned to him…Website: <a data-mce-href="https://cofound.website" href="https://cofound.website" target="_blank" rel="noopener">https://cofound.website</a><figure id="figure-35qehndfanmls7kaf6"><img id="35qehndfanmls7kaf6" src="https://cdn.durable.co/blocks/102DBxjJIIxDc0KOorrzMnQKR62UTxacIl7UzJDJDAgxOYHi5TTlxSTBM3603Cf8.png" alt="" title="" class="object-cover bg-gray-100 rounded-lg md:rounded-xl lg:rounded-2xl" style="aspect-ratio: 16/9; object-position: 0% 0%;" data-corners="default" data-aspect="16:9" data-caption="" data-positionx="0%" data-positiony="0%" data-fullwidth="false" data-mce-src="https://cdn.durable.co/blocks/102DBxjJIIxDc0KOorrzMnQKR62UTxacIl7UzJDJDAgxOYHi5TTlxSTBM3603Cf8.png" data-mce-style="aspect-ratio: 16/9; object-position: 0% 0%;"></figure> I do have follow-up questions though - for which I would love the view of any AI expert:<ul><li>It is clear that AI companies are absorbing some of the cost of running the models, what will happen once AI usage is priced at real cost? </li><li>Given that so few of my prompts are technically driven, are we now in a situation where a non-technical person can start building very complex, production-ready applications?</li></ul>I'm also happy to share the full source code if you'd like to review its quality— just drop me an email at <a href="mailto:rney@aldemis.com" data-mce-href="mailto:rney@aldemis.com">rney@aldemis.com</a>And, if you like the CoFound idea, feel free to spread the word and add your profile / project to it. It would be nice to turn it into something useful for start-up founders.* [EDIT] Following a question I received: I did indeed leave Claude to register the domain name and update the DNS settings.<h2>Prompts used</h2><h3>Software architecture &amp; first features</h3>Prompt 1:I'd like to build an application from scratch. it will be a website allowing users to register and post projects for other to comment on. I'd like the back-end to be node.js with a postgres database. what front-end technology do you recommend? --- Prompt 2:ok, let's go with React + Vite. can you start by creating a project structure please, with 2 root directories, 1 for the front-end and 1 for the back-end --- Prompt 3:could you please rename the client directory into frontend and the server into backend --- Prompt 4:if I give you the connection details for my local postgres instance, can you install the DB and run the project yourself? --- Prompt 5:localhost:5432/postgres , username is postgres and password is **************** --- Prompt 6:the front-end is empty, i was expecting to land on a login and registration page --- Prompt 7:There is no button to create a project, could you add one. I should be able to see the button on the home page but I need to be logged in to be able to create the project --- Prompt 8:there shouldn't be a username on the registration, we should use the email for the username. But I'd like to add a firstname and lastname --- Prompt 9:there is a UI display issue on the registration page, the lastname text box goes outside of the registration box --- Prompt 10:I got a registration failed message when registering --- Prompt 11:Can you also make sure the code is well documented and that there is plenty of logs for support and maintenance --- Prompt 12:After publishing the project, I get redirected to the project details page, but that page only contains a title and no project information, could you fix it please? --- Prompt 13:can we add a settings section where the user can change its password --- Prompt 14:I'd like the settings and logout link to be in a dropdown menu which appears when clicking on my name in the top bar --- Prompt 15:can we update the model so that the project publisher can add team members that he is looking for to join the project --- Prompt 16:Could we add a professional profile section so that a logged in user can fill in his profile, short description of their skills and experience, their linkedin profile URL, their availability (number of hours available per week) --- Prompt 17:could you add the ability to upload a picture on the professional profile --- Prompt 18:I'd like to split registered users into 3 categories: contributors, project lead, investors. each category should have it's own registration link so 'register as a contributor', 'register as a project lead', etc... --- Prompt 19:could we add a messaging area so that 2 logged in users can message each others --- Prompt 20:from now on, please stop asking me to confirm code changes and db changes and just proceed --- Prompt 21:only project leads should be able to create projects --- Prompt 22:i've upagraded my account, the limit should have been increased --- Prompt 23:can you add an email verification step please --- Prompt 24:here is the username and password, please update the .env file, username: ***@ethereal.email , password: ****************** --- Prompt 25:the email wasn't received, could you check what went wrong --- Prompt 26:I tried again and the email was still not received --- Prompt 27:i've updated the env file, can you restart the server please --- Prompt 28:i tried the email verification link from that email but got an error message that the verification link had expired --- Prompt 29:can you get me the last 20 lines of logs --- Prompt 30:where is the log located on the filesystem? --- Prompt 31:i just registered with a new user (firstname Karen) but I can't see anything in the logs --- Prompt 32:i've tried again (user is Luca Ney) and the call to the backend responded with a 201, but I still can't see that registration in the logs --- Prompt 33:you're running the backend for me so I can't check that, can you just give me the log file location and i'll tail it --- Prompt 34:can you run the project please --- Prompt 35:can you please start a new part of the project, in a root folder called 'admin' to create an admin portal for the application please --- Prompt 36:either i forgot my password or the login isn't working ---<h3>Initial design attempt</h3>--- Prompt 37:th eprimary color is #1a4b40 and secondary color is #ffffff pleas change those accross the whole project --- Prompt 38:how can I give you my logo so that you use it --- Prompt 39:here it is --- Prompt 40:it's here: P:\aldemis\projects\sweat-equity\logo.png --- Prompt 41:sorry, can you use this logo instead: P:\aldemis\projects\sweat-equity\logo.svg --- Prompt 42:the logo doesn't show, all i can see is a white box where the logo should be --- Prompt 43:can you increase the header size by 1.5x and make it white please, increase the logo size by the same ratio --- Prompt 44:increase by 1.5x again please --- Prompt 45:on the admin portal only, could you replace the logo with this one: P:\aldemis\projects\sweat-equity\logo_white.png ---<h3>Full Design Creation with Claude</h3>Got design built using Claude web standard version: Can you create a landing page design which should be fashionable but professional, the website is about helping start-up founders find co-founders on a sweat equity basis. The website allows founders to post their project and highlight which skill(s) they're missing and trying to get help for. Could you redesign the page with this in mind and also highlight a few of the benefits --- Prompt 46:here is a landing page design: P:\aldemis\projects\sweat-equity\landing-page.html , can you update the website design to match it, please match all logo and colors --- Prompt 47:color changes are good, but I'd also like the landing page to match the html template i provided --- Prompt 48:thanks, the grey text (#6b6b6b) is a little too dark and difficult to read, can you change it to #ababab --- Prompt 49:can you rename contributor to co-founder --- Prompt 50:and project lead as Lead Founder --- Prompt 51:please generate a relevant privacy policy and terms of use, given what the website does. --- Prompt 52:please generate 10 test users for each category of registration, as well as 5 test projects, make sure projects are posted by different test users --- Prompt 53:can you increase all fonts by 20% --- Prompt 54:can you replace the login link under the main banner by 'browse projects' --- Prompt 55:and can you add the number of projects already posted underneath it, just like the original design I provided --- Prompt 56:can you increase the fonts on the login and register page too, like you did for the home page. also increase fonts on the admin portal section --- Prompt 57:increase fonts in the admin portal by another 20% --- Prompt 58:once logged in, the browse projects link on the home page don't work --- Prompt 59:browse projects links on the home page should link to another page where all projects are displayed, they should not link to a home page section --- Prompt 60:on the project details page, please add a link to go back to the project list page --- Prompt 61:once logged in the post your project link should not appear for investor and co-founders --- Prompt 62:good work, please commit all that into a new branch called Feature/initial_build --- Prompt 63:can you push the branch to the repo please --- Prompt 64:thanks, move back to the main branch (that initial_build branch has now been merged with the main branch) --- Prompt 65:can you please extract every single prompt i've made during this project into a text file --- Prompt 66:please add a forgotton password link on the login page for both the main portal and the admin portal --- Prompt 67:the legal entity behind the website is Aldemis Ltd, 86-90 Paul Street, London, EC2A 4NE, United Kingdom, registration number 07331439 . the contact email should be cofound@aldemis.com . could you update the privacy policy and T&amp;C with that info please --- Prompt 68:can you make sure all requests and responses sent to the back-end (both portal and admin) are logged please. please make sure any password is **************** --- Prompt 69:can you make sure there is proper exception handling, and related logging, throughout the whole project please --- Prompt 70:the admin portal isn't responding anymore, could you have a look --- Prompt 71:can you configure the project to use gmail as the SMTP server, my username is donotreply@aldemis.com and the password is **************** --- Prompt 72:i don't seem to have received the email, can you check if something went wrong --- Prompt 73:the actual password has been updated to **************** , here is the app password: **** **** **** **** --- Prompt 74:it's still not working --- Prompt 75:can you run the project please --- Prompt 76:email is working, but the link in it isn't. when clicking on it, it says verification failed, invalid or expired link --- Prompt 77:it's working well. could you commit to a new branch called Feature/first_release and push it to the repo please ---<h3>App Signal &amp; Containerization</h3>Prompt 78:can you now configure the project for appsignal --- Prompt 79:********-****-****-****-************ --- Prompt 80:appsignal doesn't seem to be receiving any data, could you check what's wrong? --- Prompt 81:still not working, here is what appsignal suggests: Check your log file and the docsSee if appsignal.log is reporting errors.The debugging docs page contains further debugging instructions. Run our diagnostics toolRun npx @appsignal/cli diagnose to generate a diagnostics report.Email it to us for help! --- Prompt 82:can you containerise the project and push to docker. docker is already installed locally --- Prompt 83:here is the error i'm getting: unable to get image 'sweatequity-admin': error during connect: Get "http://%2F%2F.%2Fpipe%2FdockerDesktopLinuxEngine/v1.49/images/sweatequity-admin/json": open //./pipe/dockerDesktopLinuxEngine: The system cannot find the file specified. --- Prompt 84:There isn't any data anymore, is this a DB connection issue? ---<h3>AWS deployment</h3> Prompt 85:Here is my Aws access key: AKIA**************** and secret: ************************************. Please install the full project on AWS. Use the existing vpc and subnet. It's for demo only so go for a cheap setup. Main website should respond to HTTPS://www.cofound.website, please setup SSL certificates. Admin portal should respond to HTTPS://admin.cofound.website --- Prompt 86:can you commit everything into a new branch called Feature/container-and-deployment and push to the repo --- Prompt 87:can you summarise to me what you did to deploy it to AWS please --- Prompt 88:sorry, I should have said, could you move everything to eu-west-2 --- Prompt 89:have you made any code changes that need to be committed? --- Prompt 90:please commit and push --- Prompt 91:can you please extract all prompts I've made in this project into a text file --- Prompt 92:please update the file to only include the prompt, none of the analysis or context you provided. could you also obfuscate any password or keys

What value does AI truly deliver?

<h2>Imbalance Between Business Leadership and Technology Leadership</h2>I have spent a large portion of my career being parachuted into dysfunctional technology environments and attempting to recover them. Most of the time, the disconnects are relatively small and can be resolved fairly quickly; once in a while, however, I encounter a situation that truly amazes me in how bad things have become.When a situation deteriorates too far before someone attempts to steer the ship back into calmer waters, the problem can turn into a serious business issue. Sometimes, new feature development has to stop entirely to make room for technical refactoring or even a complete technology rebuild. As a CEO, there are few things worse than hearing that not only will you need to spend more on technology in the short term, but you also won’t be evolving your product features. It truly feels like a lose–lose scenario.I recently joined one of these projects again, which led me to question the root causes of the problem. Why do some environments become so much worse than others?After reflecting on the topic, I believe the issue stems from an imbalance between the power held by business leaders and the power held by technology leaders.Building technology that aligns with business needs requires a delicate balance of power.<h3>Dominant ‘technology’ voice</h3>If the technology voice is too dominant, a high-quality product will be built, one that runs very well, but it will become increasingly slow to evolve. Costs will continue to rise, often beyond what the business can reasonably afford. In these situations, we often see companies run out of money before they find a product–market fit.<h3>Dominant ‘business’ voice</h3>If the business voice is too prominent, too much emphasis is placed on features and speed to market, and not enough on software quality. In these environments, discussions tend to focus heavily on estimates, with business leaders frequently making statements such as “It’s as simple as ABC” or “It shouldn’t take long.” Every task that exceeds its estimate is aggressively scrutinized, and we often hear questions like, “How can we get this resolved faster?” or “The original estimate was X, what happened?” This pressure leads to significant corner-cutting by the technology team, resulting in a product that appears to work but doesn’t truly function as it should. The quality is too poor to scale, or even to survive beyond a few months.<h3>Balance</h3>Finding the right balance is difficult, and that balance will evolve as the business grows and its needs change over time. That’s why it’s essential to have open discussions and ensure that both business and technology leaders genuinely listen to each other and reach the right compromises. Give each other space to voice opinions honestly, and don’t lead with an answer. If you start with, “Give me an estimate for X, but it shouldn’t take too long because…,” don’t be surprised when corners are cut and things go wrong.If you need help determining the right level of quality for your business today, we’d be very happy to help. Click <a data-mce-href="https://aldemis.com/contact" href="https://aldemis.com/contact" data-mce-selected="inline-boundary">here </a>to contact us.

Imbalance Between Business Leadership and Technology Leadership

<h2>Why Your Million-Pound Strategy Is Stuck in the Engineering Department</h2> Your strategy is strong and your market opportunity is real. Your roadmap could add millions to the bottom line. So why does it feel like every major initiative gets stuck somewhere between the boardroom and the engineering department?It’s not because your people are incompetent. It’s not because your tech is outdated. It’s not because you “need more developers.”It’s because your business and technical brains are speaking two different languages and no one is translating.According to the Aldemis strategy research, this business–tech disconnect is the single biggest reason scale-ups stall. CEOs, COOs and boards are focused on commercial outcomes and strategic urgency. Engineers are focused on risks, dependencies and implementation realities. Both sides are right, yet they consistently interpret the same strategy in completely different ways.When this divide widens, the symptoms appear quickly:<ul><li>Projects slow down</li><li>Communication becomes defensive</li><li>Teams feel misunderstood</li><li>Politics creep in (“Don’t let the board know”)</li><li>Strategy becomes abstract instead of actionable</li></ul> Eventually, the business starts to believe the tech team is unmotivated. In reality, as Aldemis’ case examples show, most teams are simply coding in a vacuum. They don’t understand the purpose behind the product and don’t see how their work drives the mission. When purpose disappears, performance follows.This isn’t a departmental battle, it’s a translation problem at the top. The uncomfortable truth is that CEOs can’t solve this alone.You can have vision. You can have strategic clarity. You can even be technically literate.But you cannot be simultaneously impartial, embedded, politically neutral and fluent in both the commercial and engineering world. That’s why so many companies turning over £3–10 million find scaling painful, the internal structure simply wasn’t built for the next stage of growth.This is where an external, non-exec style bridge becomes essential.The Aldemis strategy defines this bridge as “the marriage, not the compromise” between business and technology. Someone who can sit in the boardroom and in the stand-up and translate without bias. Someone who can surface the unseen blockers, cultural, political, structural, long before they become expensive. Someone who can turn a CEO’s vision into a roadmap the engineering team believes in, understands and can execute.Because strategy doesn’t fail in the engineering department, it fails in translation.When every layer of the business finally speaks the same language:<ul><li>The roadmap becomes achievable</li><li>Teams regain motivation and purpose</li><li>Communication becomes clean and fast</li><li>Politics evaporate</li><li>Revenue-driving change happens quickly</li></ul> A million-pound strategy only delivers if the people building it are aligned with the people designing it. If your strategy is stuck, the answer isn’t another tool or another restructuring.It’s fixing the connection.At Aldemis, that’s exactly where we operate, bridging the gap between technology and business so CEOs can scale with confidence and teams can build with purpose.When the business and engineering worlds finally understand each other, the growth stops stalling and instead starts accelerating.Book an <a data-mce-href="https://aldemis.com/contact" href="https://aldemis.com/contact">introduction call</a> today.

Why Your Million-Pound Strategy Is Stuck in the Engineering Department

<h2>The Elusive Unicorn: What a "Good" CTO Truly Looks Like for Your SaaS Business</h2>For SaaS CEOs, the Chief Technology Officer (CTO) is arguably the most pivotal hire after themselves. This isn't just about managing code, it's about steering the technological ship that carries your entire product and business vision. But what exactly defines a "good" CTO, and how do you weigh the merits of a deep-dive technologist against a business-savvy strategist?The ideal CTO is a rare blend, a genuine "unicorn" who can bridge the chasm between cutting-edge technology and commercial reality. They are not merely the head of engineering; they are a strategic partner who understands that every line of code and every architectural decision must ultimately serve the customer and the bottom line.The Hallmarks of a Good SaaS CTO A truly effective CTO for a SaaS business exhibits a constellation of qualities:<ol><li>Strategic Visionary: They don't just react to market trends; they anticipate them. A good CTO understands the broader industry landscape, emerging technologies, and how these can be leveraged (or defended against) to create a sustainable competitive advantage for your product. They translate business goals into a clear, actionable technology roadmap.</li><li>Product-Oriented Mindset: While they lead technology, their focus remains firmly on the product. They understand the user experience, empathise with customer pain points, and champion technical solutions that directly enhance product value, scalability, and reliability. They're not building tech for tech's sake.</li><li>Exceptional Communicator and Leader: The CTO must be able to articulate complex technical concepts to non-technical stakeholders (board, sales, marketing) and inspire their engineering team. They foster a culture of innovation, accountability, and continuous improvement, attracting and retaining top talent.</li><li>Architectural &amp; Scalability Acumen: They possess a deep understanding of scalable, secure, and robust software architecture. For a SaaS business, this is non-negotiable. They can foresee future bottlenecks and design systems that can grow with your user base and feature set without collapsing under their own weight.</li><li>Risk Management: They are pragmatic about technical debt, security vulnerabilities, and infrastructure risks. A good CTO knows when to build, when to buy, and when to refactor, always balancing speed with stability and long-term maintainability.</li></ol> The Technical Guru: Pros and Cons of the Deeply Technical CTOA CTO with profound technical depth often comes from a background of hands-on coding, architecture, and solving complex engineering challenges.Pros:<ul><li>Credibility with Engineers: Their technical prowess earns immediate respect from the engineering team. They can dive into code reviews, understand intricate system designs, and mentor junior engineers effectively.</li><li>Strong Technical Decisions: They are well-equipped to make sound architectural choices, evaluate new technologies, and identify potential technical pitfalls. This can lead to a more robust, efficient, and innovative product.</li><li>Problem Solver: When a critical bug arises or a technical challenge seems insurmountable, their deep understanding can be invaluable in quickly diagnosing and resolving issues.</li><li>Innovation Driver: They are often at the forefront of new technologies, ensuring your product leverages the best tools and approaches.</li></ul>Cons:<ul><li>Risk of "Tech for Tech's Sake": A purely technical CTO might prioritise elegant solutions over business value, leading to over-engineering or focusing on non-critical technical challenges.</li><li>Limited Business Acumen: They might struggle to translate technical capabilities into market opportunities, understand customer needs from a business perspective, or align technology initiatives with sales and marketing goals.</li><li>Poor Communication: May find it challenging to communicate effectively with non-technical stakeholders, leading to misunderstandings, misaligned expectations, and a perception of the tech department being a "black box."</li><li>Delegation Challenges: They might find it hard to delegate technical tasks, preferring to get involved in the weeds, which can hinder team growth and operational efficiency.</li></ul> The Business Strategist: Pros and Cons of the Business-Focused CTOThis type of CTO often has a stronger background in product management, business development, or even a general management role, with a solid understanding of technology's strategic implications.Pros:<ul><li>Strong Business Alignment: Excels at linking technology strategy directly to business objectives, market opportunities, and revenue growth. They're likely to be a strong voice in executive-level strategic planning.</li><li>Customer &amp; Market Focused: Better at understanding market demands, competitive landscapes, and customer feedback, ensuring technology investments directly address these.</li><li>Effective Cross-Functional Collaboration: More adept at communicating with other departments (sales, marketing, finance) and ensuring technology serves their needs, fostering a more integrated company.</li><li>Focus on ROI: Prioritises features and technical initiatives that promise the clearest and most significant return on investment.</li></ul>Cons:<ul><li>Lack of Technical Depth: May struggle to earn the full respect of the engineering team if they can't genuinely understand or contribute to deep technical discussions. This can lead to a perception of being out of touch.</li><li>Poor Technical Decision Making: Without a strong technical foundation, they might approve suboptimal architectural choices, underestimate technical debt, or struggle to evaluate the feasibility/complexity of certain features.</li><li>Difficulty in Recruiting Top Talent: Highly technical engineers often prefer working under a CTO who can genuinely mentor and challenge them on a technical level.</li><li>Overreliance on Engineering Leads: May be too dependent on their engineering managers or architects for core technical decisions, potentially leading to a lack of cohesive technical vision at the top.</li></ul> Finding Your Unicorn The sweet spot lies in a CTO who possesses significant technical acumen but also has a strong commercial mindset. They don't need to be the best coder in the company, but they must understand system architecture, modern development practices, and the technical challenges your team faces. Crucially, they must also speak the language of business – revenue, profit, customer acquisition, and market share.When hiring, look for:<ul><li>Evidence of strategic thinking beyond just technology – how have they used tech to solve business problems?</li><li>Strong communication skills across technical and non-technical audiences.</li><li>A track record of scaling teams and systems in a fast-paced environment.</li><li>An understanding of your specific SaaS domain and its unique technical challenges (e.g., security, multi-tenancy, data analytics).</li></ul>Ultimately, your CTO is the architect of your product's future. By carefully weighing these factors and understanding the nuanced pros and cons, you can find the leader who will build not just great software, but a great, sustainable SaaS business.<h3> Are you wondering what this means, in practice, for your business? </h3><a data-mce-href="https://aldemis.com/contact" href="https://aldemis.com/contact">Contact us</a> to discuss. &nbsp;

The Elusive Unicorn: What a "Good" CTO Truly Looks Like for Your SaaS Business

<h2>Why Purpose Matters? A Real-Life Story</h2>About 10 years ago, our CEO, Richard Ney, witnessed something which became a key trigger for what Aldemis is today.Richard had been brought into a large organisation (£250M+ ARR) as they faced significant business issues that were deeply impacting their bottom line. It was perceived that one of their main reason was due to one of their software teams underperforming. The quality of the software was low, releases were going out the door late and running over budget, and the team experienced an extremely high level of turnover.Those facts were accurate, and the reason for it was apparent; the resolution was straightforward. The result was mindblowing!The team, about 50 people across product, development, testing, release &amp; support, was working on an end-of-life product. The software was old and complex; few new features were being worked on, and the work consisted mainly of BAU bug fixes, which were uninteresting to work on. To top it up, although it was not official, everyone knew the product was going to be retired within a few years. The team was simply unmotivated, and the performance was very poor.After a month into the business, Richard asked the CEO and CPO if they could spare 30 minutes to talk to the team and explain where the product fit within the organisation. What happened was truly extraordinary.The 50 people were packed into the boardroom (there wasn’t any realistic way to do it at the time), and then the CPO arrived, followed by the CEO. They spoke to the team and explained that the system was indeed a ‘cash cow’ type of product, planned for retirement within 3 years. They explained that a new product would be introduced as a replacement and that the team would transition to it afterwards.In the meantime, the business needed the current software to remain stable, as it was generating 80% of the revenue. 80%!They explained that most people in the office were being paid thanks to that product, and therefore, the work the team was doing to keep it stable was truly appreciated. Every time the system failed and had to be turned off, 80% of the revenue for that period was lost. It was simply the best product the business had until the replacement came in.That view on the position of their work and its importance to the business made the team realise the extent of their contribution. They now understood why someone had to maintain that system.The situation changed literally overnight. Turnover stopped, productivity increased, and the team became very proud of their work. They understood their purpose and value!Of course, such a significant business problem wasn't caused solely by one team, so once the software team's issue was fixed, Richard went on to help identify and resolve many other issues within that part of the business. But that's another story... This real-life story was a realisation for Richard, and we’re now using some of those principles (and others) to boost business productivity within our customers’ team.Across the years, we’ve learnt some DOs and DONTs when it comes to team motivation, and we’re sharing some with you here:<h3>The 5 DOs</h3>1. DO: Foster a Sense of Purpose and Impact Engineers and developers are, at their core, problem-solvers. While they enjoy tackling complex technical challenges, their motivation skyrockets when they understand why they are solving a particular problem. It's not enough to assign a ticket from a backlog; you must connect their work to the bigger picture. Clearly articulate how the feature they are building will alleviate a customer's pain point, drive business growth, or contribute to the company's mission.Regularly share customer feedback, business metrics, and success stories. For example, instead of saying, "We need to build an API for data export," try, "Our enterprise clients are struggling to integrate their data, which is a major blocker for renewals. By building this API, you'll be directly enabling our top 10 customers to succeed and securing millions in revenue." This transforms a technical task into a meaningful contribution, giving them a clear line of sight from their code to real-world impact.2. DO: Grant Autonomy and Trust Once the "what" and the "why" are clear, the best thing a leader can do is step back and trust the team with the "how." Technology professionals are highly skilled experts who thrive on autonomy. Micromanaging their technical decisions, dictating specific implementation methods, or requiring constant status updates erodes trust and stifles creativity. Empower your team to make decisions about their architecture, tools, and processes.This doesn't mean a complete hands-off approach. It means setting clear goals and constraints and then giving them the space to figure out the best path forward. Encourage debate, let them experiment (and sometimes fail), and support their technical choices. When you show that you trust their expertise, they will take greater ownership and pride in their work, leading to more robust and innovative solutions. This sense of ownership is one of the most powerful intrinsic motivators.3. DO: Invest in Growth and Learning The technology landscape changes at a dizzying pace. What is cutting-edge today is standard tomorrow and legacy the day after. For this reason, top tech talent is deeply motivated by opportunities to learn and grow their skills. Stagnation is a career-killer, and a team that isn't learning is a team that is falling behind. Actively investing in their development shows that you value them as professionals, not just as cogs in a machine.This investment can take many forms: provide a budget for online courses, books, and conferences; allow "hack days" or "20% time" for experimentation with new technologies; and encourage knowledge-sharing through tech talks or brown-bag sessions. Furthermore, create clear career paths that allow for growth as an individual contributor (e.g., Staff/Principal Engineer) as well as a manager. When team members see a future for themselves at the company, they are far more likely to stay engaged and motivated.4. DO: Protect Their Time and Focus One of the biggest demotivators for a technical team is constant context-switching. Deep technical work, like coding or system design, requires long, uninterrupted periods of concentration, often called "flow state." Every unplanned meeting, shoulder-tap, or urgent Slack message can break that flow, costing significant time and mental energy to regain focus. A great leader acts as a "shield" for their team, protecting them from this chaos.Be ruthless about scheduling. Question the necessity of every meeting and ensure it has a clear agenda and only the essential attendees. Funnel external requests through a single point of person (like a product manager or team lead) rather than letting stakeholders approach developers directly. Establish "no-meeting" blocks of time and respect the team's need for focus. By fiercely guarding their most valuable resource—their time—you enable them to do the deep, satisfying work they were hired for.5. DO: Recognize and Reward Both Effort and Outcome Recognition is a powerful motivator, but it must be applied thoughtfully. It's crucial to acknowledge not just the successful launch of a major feature but also the "invisible" work that makes it possible. This includes recognizing the engineer who spent a week refactoring complex legacy code to improve stability, the person who wrote excellent documentation that unblocked the rest of the team, or the one who patiently mentored a junior developer.Make recognition specific, timely, and authentic. A public shout-out in a team meeting or a private message highlighting a specific contribution can be incredibly meaningful. While financial rewards are important, don't underestimate the power of acknowledging the craft, effort, and teamwork that often goes unnoticed. This builds a culture where quality and collaboration are valued, encouraging the behaviors you want to see repeated.<h3>The 5 DON'Ts</h3>1. DON'T: Micromanage the "How" This is the direct counterpart to granting autonomy and is perhaps the fastest way to demotivate a skilled professional. Micromanagement sends a clear message: "I don't trust your judgment or your skills." Questioning every technical decision, demanding to be included in every pull request review, or dictating the exact way a problem should be solved strips engineers of their agency and creativity. It turns them from creative problem-solvers into typists who are simply executing someone else's commands.If you have concerns about a technical direction, frame it as a question to foster discussion rather than a directive. For instance, instead of saying "You must use a NoSQL database for this," ask, "Have we considered the scalability trade-offs between a relational and a NoSQL database for this use case?" Trust that you hired smart people, give them the context and the goals, and let them demonstrate their expertise. Your role is to guide and unblock, not to control.2. DON'T: Ignore Technical Debt Technical debt is the implied cost of rework caused by choosing an easy (limited) solution now instead of using a better approach that would take longer. Every engineering team accumulates it. However, consistently forcing the team to build new features on a shaky or poorly-architected foundation is profoundly demoralizing. It's like asking a chef to cook a gourmet meal in a dirty kitchen with broken appliances. It's slow, frustrating, and the results are often subpar.Ignoring technical debt signals to the team that management prioritizes short-term speed over long-term quality and stability. This leads to burnout as engineers fight the same fires over and over again. A motivated team is one that is allowed to take pride in its craftsmanship. Actively budget time for refactoring, paying down debt, and improving infrastructure. This shows the team you respect their craft and are invested in the long-term health of the product and their own sanity.3. DON'T: Tolerate "Fire Drills" and Constantly Shifting Priorities While business needs can change, a constant state of emergency or "fire drills" will burn out your team. When priorities shift daily and the project they’ve poured their energy into is suddenly de-prioritized or canceled without clear reason, it creates a sense of futility. Their hard work feels wasted, and they begin to question the value of starting any new project with dedication. This "whiplash" effect makes it impossible to plan work, maintain focus, or feel a sense of accomplishment.As a leader, your job is to create a stable and predictable environment. Work with product and business stakeholders to establish a clear, prioritized roadmap and communicate changes with transparency and a strong rationale. Protect the team from reactive, "flavor-of-the-day" requests. When an urgent issue does arise, clearly define its priority relative to existing work. Predictability and stability allow a team to build momentum and derive satisfaction from completing what they start.4. DON'T: Treat Them as a "Feature Factory" A technology team is not a vending machine where you insert a specification and a feature comes out. They are your company's greatest source of innovation and problem-solving. If you treat them solely as implementers and exclude them from the discovery and planning phases, you are missing out on their most valuable contributions. This approach is also deeply demotivating, as it reduces their role to that of a "code monkey" and ignores their analytical and creative skills.Involve your engineers early in the product development lifecycle. Bring them into brainstorming sessions, have them participate in customer interviews, and ask for their input on feasibility and alternative solutions. They often have a unique perspective that can lead to simpler, more elegant, and more technically sound solutions than what a product manager might have initially envisioned. When they are partners in solving the problem, not just builders of the solution, their engagement and ownership increase dramatically.5. DON'T: Foster a Culture of Blame When a production issue occurs, a deadline is missed, or a bug makes it to a customer, the worst possible reaction is to ask, "Whose fault is this?" A culture of blame creates fear, which kills psychological safety. When people are afraid to make mistakes, they stop taking risks, stop innovating, and start hiding problems instead of raising them. This is toxic to a high-performing technology team, where experimentation and learning from failure are essential.Instead, cultivate a culture of blameless post-mortems. The focus should be on understanding the systemic causes of the failure, not the individual who made the error. Ask "What went wrong?" and "How can we improve our processes to prevent this from happening again?" not "Who did this?" When your team knows they can report a problem or admit a mistake without fear of punishment, you create a resilient, transparent, and continuously improving organization where everyone feels responsible for collective success. <h3>Are you wondering what this means, in practice, for your business?</h3><a data-mce-href="https://aldemis.com/contact" href="https://aldemis.com/contact">Contact us</a> to discuss.

Blog

Software is more than just features

What value does AI truly deliver?

Imbalance Between Business Leadership and Technology Lead...

Why Your Million-Pound Strategy Is Stuck in the Engineeri...

The Elusive Unicorn: What a "Good" CTO Truly Looks Like f...

Why Purpose Matters? A Real-Life Story