Metric of the moment – Sales Velocity, and how to use it to boost sales

There are so many metrics. Today we’re only going to look at Sales Velocity. We like this one because it’s not just the number that’s useful. The entire formula, short as it is, acts like a mini-guide to where you need to put your effort to boost sales. 

Sales Velocity is typically used by companies with sales teams, but there’s an equivalent for self-serve B2B and B2C businesses as well – Revenue Velocity. We’re going to cover both and tell you how to use them. 

What even is Sales Velocity and why should you care

Sales Velocity measures how quickly your business (or your sales team) generates revenue by doing math that focuses on the timing and effectiveness of your sales process. As you’ll see, the numbers tracked as part of Sales Velocity means you can use it to:

This metric is particularly useful for B2B companies with longer sales cycles and higher deal values. There are also B2C businesses that can benefit from it, especially those with products or services that have higher ticket prices and longer consideration periods. Often these are businesses with a digital funnel but a very bricks-and-mortar product – renovations, kitchens, and custom furniture fit into this category.

How to calculate your Sales Velocity

Sales Velocity is calculated from four numbers:

  1. Number of Opportunities: All the deals in your pipeline for a given period.
  2. Average Deal Value: Total revenue divided by the number of closed deals.
  3. Win Rate: The percentage of deals you’ve won out of total opportunities.
  4. Length of Sales Cycle: The average time it takes to close a deal.

Here’s the formula:

Sales Velocity = (Number of Opportunities × Average Deal Value × Win Rate) ÷ Length of Sales Cycle

And here’s an example: 

Let’s say last month you had 50 opportunities in your pipeline. Your average deal value was $5,000, your win rate was 20% (not bad), and the average length of your sales cycle was 30 days.

Sales Velocity = (50 × $5,000 × 0.2) ÷ 30 = $1,666.67

This means your sales process is generating $1,666.67 per day in revenue.

Making Sense of the Results

Once you’ve got your Sales Velocity, it’s time to interpret it. Don’t just look at the final number. It won’t mean anything on its own, but it will after a few months of tracking it. What you want to look at is all the numbers laid out in the formula.

A low number might point to specific issues:

You can’t improve what you don’t measure. Sales Velocity gives you four components – four numbers – you can work on improving. We can’t tell you which one to work on first. You know your business better than anyone. 

Start with focusing on the component that will have the biggest impact on your Sales Velocity. Set clear goals and track your progress monthly. If you can’t move it, or it stops moving, look at your Sales Velocity equation again and pick the next component you can impact the most. Rinse and repeat.

Revenue Velocity: The Self-Serve Business Equivalent

For self-serve B2B SaaS or B2C e-commerce businesses, “Revenue Velocity” is the equivalent metric. It measures how quickly and efficiently you convert website visitors into paying customers.

The components are similar, but tailored to online businesses:

  1. Number of Transactions: Total purchases or signups in a given period
  2. Average Transaction Value: Total revenue divided by number of transactions
  3. Conversion Rate: Percentage of visitors who make a purchase
  4. Time to Purchase: Average time from first interaction to purchase

The formula looks like this:

Revenue Velocity = (Number of Transactions × Average Transaction Value × Conversion Rate) ÷ Time to Purchase

Example: Let’s say last month you had 200 transactions with an average value of $100 each. Your conversion rate was 5%, and it took customers an average of 7 days from their first interaction to purchase:

Revenue Velocity = (200 × $100 × 0.05) ÷ 7 = $142.86

This means your self-serve business generated $142.86 per day in revenue from transactions.

To calculate it, you’ll need to dig into your web analytics and e-commerce platform data. Tools like Google Analytics, combined with your e-commerce platform’s reporting features, can provide most of this information.

Interpreting Revenue Velocity

Just like Sales Velocity, Revenue Velocity gives you four numbers you can work on to improve your sales.

For example, you can:

You will know best what resources you have available and which components will give you the best return on your efforts. Then it’s just a matter of monitoring your progress and moving onto the next component once the gains slow.

The standard “Make numbers go up” process

Whether you’re using Sales Velocity or Revenue Velocity, these metrics can help you select and monitor the facet of your sales process that will give you the biggest boost.

While we’ve already discussed the process (twice), here’s a better outline of what you need to do:

  1. Identify your most likely win: Look at each component of the formula and determine which one is going to be easiest to boost and improve your overall velocity. 
  2. Set Specific Goals: Once you’ve identified the component to work on, set a concrete, measurable goal for improvement. For example, “Increase win rate from 20% to 25% in the next quarter.”
  3. Develop an Action Plan: Create a detailed plan to achieve your goal. For win rate this might involve sales training, process optimisation, or new marketing initiatives.
  4. Implement and Monitor: Put your plan into action and closely monitor your progress. Be prepared to adjust your approach based on the results you see.
  5. Reassess Regularly: Recalculate your velocity metric monthly and reassess your focus area. As you improve one component, another may become the new priority.

The Bottom Line

Whether you’ve got a sales team or your business is self-serve, Sales Velocity and Revenue Velocity are a simple, easily understood metric that both bring you four levers you can pull to boost your revenue.  

Knowing which levers there are to pull is the most important part of the process and these metrics give you them for free. Everything else is up to you and your team. 

Getting Ahead of AI Legislation in Your Product Planning

You’re probably planning on using AI in your product. You might be sitting on a stash of proprietary data your business has collected over the years it’s been in operation – a database full of transactions or a file system full of documents. Or you might be looking at how your product can collect data and leverage AI during its day-to-day usage by your customers. 

The Australian government, like the EU, the US, UK, Canada and a host of other nations, has started the move towards legislating AI. After a process involving discussion papers, think tanks, and community consultation, the government has proposed that mandatory guardrails for AI be put in place. This is on top of the 10 voluntary guardrails for AI.

What those guardrails involve depends on if your usage or AI counts as high risk or low risk.

High Risk vs Low Risk AI 

It is a kind of one-sided definition. High Risk AI is AI that can result in these impacts:

If your use of AI doesn’t fall into any of those categories then it might be Low Risk. Might be. There will be much talking to lawyers by businesses to come to terms with these coming changes.

There is another category, above High Risk, which governments are particularly concerned about: General Purpose AI (GPAI) models. These are defined as highly capable AI systems that can be adapted for various purposes, making it difficult to foresee all potential risks. What models get this classification, if any at the moment, is undecided, but GPAI will require mandatory guardrails.

Understanding the Government’s Perspective

Governments worldwide are deeply worried about how fast AI is simultaneously advancing and being adopted and how the impacts of these two paths are going to play out. 

Concerns grow out of big business’s excitement at the wholesale replacement of expensive employees with AI colliding with the inherent fallibility of AI, that plays out as “hallucinations” and getting “obvious” things wrong that anyone who uses AI regularly experiences.

So governments are intent on:

But at the same time everyone recognises that AI is going to cause a major shift in how the world works and how it is organised. No-one wants to be left behind, so governments want to foster AI usage, but they also want to balance it against public interests.

As they say, may you live in interesting times.

Impact of AI Legislation on Products and Data

As you consider the potential impact of AI regulations on your business, it’s important to understand which products and data types are likely to be affected and which might remain relatively unscathed.

Products and data likely to be impacted:

Products and data less likely to be impacted:

It’s worth noting that the degree of impact may vary depending on the specific use case and the sensitivity of the data involved. You’ll need to carefully assess where your products and data fall on this spectrum.

How AI Legislation Might Play Out For Different Businesses

To better understand how different businesses might incorporate regulatory requirements, let’s examine three hypothetical companies in various sectors:

PropTech: RentSmart Solutions 

RentSmart Solutions provides comprehensive rental management services, including tenant selection, rental payments, and communications.

Regulatory considerations:

Compliance strategies:

Food Delivery: FeastFleet 

FeastFleet is a food delivery app that uses location information for deliveries and historical order data for driver allocation, restaurant recommendations, and discount offers.

Regulatory considerations:

Compliance strategies:

FinTech: MicroShares 

MicroShares is a fintech app that allows users to buy and sell partial shares in stocks on demand.

Regulatory considerations:

Compliance strategies:

These fictional micro case studies demonstrate how businesses in different sectors can proactively address regulatory concerns while building products around AI.

Strategies for Compliance and Adaptation

As you’re working out your product strategy you’re going to want take a whole list of things into consideration. This is that list:

  1. Prioritise transparency and explainability: Ensure your systems can clearly articulate how decisions are made, especially if your product and its usage of AI falls in the High Risk category.
  2. Implement robust data governance: Establish clear protocols for data collection, storage, and usage. If your product has an international audience you may already by intending to comply with privacy regulations like GDPR or CCPA.
  3. Conduct impact assessments: Evaluate the potential risks and societal impacts of your AI systems.
  4. Foster a culture of responsible AI: Invest in training your team on ethical AI practices and create internal guidelines for AI development and deployment.
  5. Consider alternative approaches: If certain applications become heavily regulated, explore less regulated areas or focus on developing AI tools that augment human decision-making rather than replace it entirely.
  6. Stay agile and adaptable: Be prepared to pivot your product strategy or business model if necessary, keeping a close eye on regulatory developments.

For a deeper dive and a guided process on assessing your AI use, the Department of Industry, Science and Resources has published the AI Impact Navigator along with a set of tools and templates for using it. 

Wrapping it all up

Chances are your use of AI falls in the Low Risk category. And as long as you practice good data governance and fulfill any required privacy regulations around the data you collect then the burden of any new AI legislation will probably be minimal.

If your product falls into the High Risk category – and that is where many profitable niches live (within the health and finance domains) – then you need to be prepared to deal with the requirements.

On the bright side, by the time the AI legislation rolls into law there will probably be AI-based tools to help you with achieving compliance anyway.

The Business Case for Cross-Platform App Frameworks – There can be Only 1

When you’re building out a digital platform you want to get in front of as many potential customers as possible. You want a website, an iPhone App, and an Android app. And of course you need a backend that all three pull data from that also handles authentication, billing, reporting, and administration features.

Depending on how good your Google skills are (or how recent your AI’s training data is) you’ll find up to 10 options for building cross-platform apps. And each of those options will come with a list of pros and a list of cons. In this article we’re going to make the case that there are really only 3 options you should be considering, and for most people there are only 2. 

Choosing between them is remarkably simple. So simple we’ll lay out what we think is the best strategy right now:

Build your apps using React Native unless your business is built on Microsoft’s stack and you have a bunch of .Net programmers in-house, in which case use their .Net Maui framework (formerly known as Xamarin).

The only reason to choose anything else is because you have decided that you have complex UI requirements that need pixel-level control of the interface or your market is predominantly Android. In which case, use Flutter from Google. Unless what you’re really making is a game.

The business case for using React Native to build cross-platform apps

React Native grew out of the React ecosystem. React is the world’s most widely used web native front-end framework. It is written in JavaScript and it is almost always paired with a Node backend, also written in JavaScript, though being a front-end framework it doesn’t care how your backend is implemented.

In our article “Should you build an app or a website” we discuss how starting your digital platform with a React-based website makes later app development easier (especially if you did the smart thing and chose to design your site to be mobile-first). From the base of React, building an app using React Native allows you to take advantage of the design, architecture and coding work you’ve already completed.

This single language full-stack architecture from your backend to your apps on your users phone provides a cohesiveness in your development process. Having all your developers working in the same language and using the same tools creates “synergies” as people like to say.

So, the business case for React Native is based on:

The business case for using .NET Maui to build cross-platform apps

.NET Maui started life as the cross platform framework Xamarin. Microsoft bought Xamarin in 2016 and in May this year announced it was no longer supporting it as all functionality, and more, was now in .NET Maui. Maui is still open source, like the original Xamarin.

Unlike React Native, which grew out of Facebook’s need to have a universal presence on devices without relying on a proprietary toolchain, Maui grew out of Microsoft’s strategic desire to provide cross platform development that benefited Windows. Xamarin initially targeted IOS, Android and Windows Phone. A MacOS target was added in 2012. After Microsoft purchased Xamarin they (had no choice) migrated away from Windows Phone to Windows desktop applications. This is a way for Windows to remain relevant in a world where businesses and thus apps are mobile-first.

The business case for using Maui is pretty simple – you’re a Microsoft house. That’s it. Why complicate things by hiring a bunch of JavaScript developers or some Dart developers (for Flutter) and building a secondary stack with its own servers and toolchains?

Every framework has its quirks. But building with Maui results in native apps on each platform using the native UI elements so your users aren’t going to notice or care. 

The business case of using Flutter to build cross-platform apps

Flutter by Google is their response to the bald fact that most app-related spending happens on IOS. That’s where users are getting out their wallets. Android phones outnumber iPhones almost  3:1 but iPhone users’ spending is more than double Android users:

Android & iOS spending

Many apps don’t even have an Android version. Or if they do, it is released long after the iPhone version.

But note – that chart is spending on apps in app stores. This does not include things like paying for an Uber or DoorDash. We haven’t been able to find a breakdown of total spending via phone based on platform, so we’re using app spend as an indicator.

For Google that chart is a problem. Why look at that chart and then develop for Android if the money is on iOS? Flutter is their solution – develop for both. And as a solution it is technically clever, because they’re Google, but a little half-baked in the User Experience for iOS, also because they’re Google.

Flutter works by giving you complete control over what gets drawn on a phone’s screen. They make it easier for you by supplying widgets that implement Material – Google’s UI framework – and widgets that are re-implementations of Apple’s Human Interface Guidelines. UI is more than pixels – it’s also behaviours, animations, and integrations (such as accessibility for vision impaired). While Google controls Material, it is always lagging behind on any changes Apple makes to its UI, making Flutter a first class citizen on Android, but second class on iOS.

But this might not matter. 

The business case for using Flutter follows three lines:

  1. You have a special app that needs a special interface that must ignore the UI guidelines on both platforms
  2. Your market is predominantly on Android
  3. 2 + your business growth requires access to the entire market

For 1, be really sure you need this. And if the special interface is because you’re building a game or an app that has a game-like interface, consider using an actual game engine instead, like Unreal or Unity. They’re also cross-platform.

Now 2 is very common. Android outsells iPhones. In emerging markets Android dominates phone sales. The decision to go with Flutter relies on you understanding the demographics of your market and their spending habits. What you miss out on asking price can you make up on volume? Is the app your business or the interface to your business (eg Netflix, Uber, DoorDash, etc)?

Line 3 doesn’t require any explanation. If you have to grow you have to grow.

Which business case are you?

We hope this cleared up the decision making around apps for you. It’s really all about what your existing platform and the availability of talent. 

We are big on React Native, but are also fans of .NET Maui. Though, React Native fits so nicely into an incremental growth strategy it’s what we lean towards if you’re starting from scratch.

If you have any questions about app development or growing your digital platform we’re always up for a chat about options and strategies. Hit us up.

What you need to know about Authentication – Make onboarding users painless

If you’re a small to medium business building out a digital platform or a startup you need authentication – a way to register new users and handle verifying existing users. 

Unless your product is “user authentication” this is not something we would recommend you build yourself. Resist the DIY urge, ignore the call of “Not Invented Here”, and actively shutdown the hubris of “the spec isn’t that complicated and there are plenty of reference implementations”.

The biggest argument for this is simple – user authentication is basic “product hygiene”. It’s one of the fundamental features every app and website needs to have and it is one of the features of your product your users will expect. And It has nothing to do with your Unique Value Proposition or whatever moat you are trying to build. So you shouldn’t be wasting time, money or innovation on user authentication. Spend your precious resources on building value and wire up someone else’s API to do the authentication for you.

There is a secondary argument if you are in industries with strict regulatory requirements, like fintech or health, or you want to sell to enterprise – compliance is hard. Hard means expensive and time consuming. It probably requires audits. Your potential clients would rather see a proven solution in place that lets them tick their own compliance boxes. Make it easy for them and yourself – use the API of the proven solution.

The Pros and Cons of Authentication As A Service

There’s really only one Pro of using an authentication provider – you don’t have to write the code yourself. That takes a lot of effort and responsibility off your plate once you make the decision, and it eliminates all kinds of ongoing management burdens. When your lean startup team is racing to revolutionise the property market you don’t want to lose anyone to diagnosing why password reset emails are being delayed by 2 hours and ending up in spam folders.

Instead you can let your authentication provider’s team of 40-50 developers worry about that for you. They’ve been doing it for years.

And over the years they’ve implemented things like social sign-on for Google, Apple, Facebook, Github, etc, and 2 Factor Authentication and password recovery and all the features you need to make it as easy as possible for your users to authenticate and use your product.

Now, there are several cons. Some see the biggest con as having to pay for the service. Maybe do some math around what you might be paying your developers to build an authentication system plus what you would be paying for the ongoing management of it (particularly the security side of things), add in how much it would cost you to get it wrong, and use those numbers to guide your decision. 

The next biggest con, or concern, is vendor lock-in. Providers do offer a path for migrating away from their service, but often the lock-in comes in the form of deep integration of the service into your code base. 

There are ways to mitigate this implementation-based lock-in and they are also basic good software practices. Your developers are going to be writing code that calls the provider’s API either directly or via an SDK (Software Development Kit). They can write a more generic interface to “authentication services” which allows you to swap out providers or eventually swap in your own. It’s a little more effort in the beginning, but not much more than a direct implementation for a specific provider, and it enables you to leave your options open.

Also, make sure you own any custom domains that are used as part of the authentication flow. Some users bookmark login pages, and some authentication standards use hostnames as part of their configuration (they need to know for sure where they are sending users and data). You don’t want to lose them if you change providers.

Why have authentication at all – the Magic Link

If your product is B2C and doesn’t need to secure sensitive information or payment details (because you’ve offloaded that to a service like Stripe) you may be wondering if you need authentication at all.

A current pattern that is comparatively minimalist in implementation (beyond having some solid email infrastructure or a trustworthy email provider who’ll keep you out of spam folders) is the Magic Link.

What is the Magic Link pattern?

The Magic Link pattern is where a product doesn’t ask you to register but asks for an email address and sends an email with an access link. 

This offloads authentication to email providers like Google and Microsoft (who are very good at that) and it also helps eliminate account sharing. Anthropic use this pattern to good effect. 

On the backend an account is still created in a database somewhere and the email address is the central identifier. On the browser or app side session tokens are stored and if the user has to do anything important – like pay you, change important settings – you send them another Magic Link.

Technically, it is simple to implement. Much simpler than login flows, social sign-ons, password recovery, 2FA, etc. Many users don’t like this system and the switching between applications it requires. It is not the best UX, especially on mobile. But for your product and your users it might be enough.

Who are the Authentication As A Service providers?

Here is a comparison table of the major AaaS options as of late 2024. Note that it includes KeyCloak, which is open source and self-hosted, and SuperTokens, which offers a self-hosted option. This is because we’re being thorough and they are technically not “DIY”, but both come with the burden of management. But if you need the control, you need the control. 

Try not to need the control if you haven’t launched yet.

Service Name Overview Pricing Model Key Features Integration Complexity Scalability Compliance & Certifications Customization & Control Social Logins Supported
Auth0 Comprehensive authentication platform suitable for businesses of all sizes. Free tier available; paid plans based on Monthly Active Users (MAUs) and features. Supports SSO, MFA, social logins; extensive compliance standards. Moderate; well-documented but may require setup time. High; designed for large-scale applications. GDPR, HIPAA, SOC 2, ISO 27001, and more. High; customizable authentication flows and branding. Yes (Google, Facebook, Twitter, Microsoft, LinkedIn, GitHub, Apple, and more)
Firebase Auth Authentication service by Google as part of the Firebase platform. Generous free tier; pay-as-you-go pricing for additional usage. Email/password, phone auth, social logins; tight integration with Firebase services. Easy; straightforward, especially within Firebase ecosystem. High; backed by Google’s infrastructure. Complies with Google’s security standards. Limited; less flexibility in customizing flows. Yes (Google, Facebook, Twitter, GitHub, Apple, Microsoft, Yahoo, Play Games, and more)
Clerk Modern authentication with a focus on developer experience and user interface. Free for up to 10,000 MAUs; paid plans for higher usage and features. Magic links, social logins, MFA; pre-built UI components. Easy; developer-friendly SDKs for popular frameworks. Scales with your user base; costs increase with usage. SOC 2 Type 2, CCPA compliant. High; customizable components and APIs. Yes (20+ providers including Google, Facebook, Twitter, GitHub, Apple, Microsoft, LinkedIn, Slack, Discord, and more)
Supabase Auth Open-source alternative to Firebase, integrating seamlessly with PostgreSQL databases. Free tier; affordable paid plans for additional resources. Email/password, magic links, social logins; works with Supabase services. Easy; especially if using the Supabase stack. Moderate to high; depends on your infrastructure. Self-managed compliance; open-source transparency. Moderate; customization possible with development effort. Yes (Google, Facebook, Twitter, GitHub, GitLab, Bitbucket, Apple, Azure, LinkedIn, Twitch, Discord, Slack, Spotify, Notion, and more)
FusionAuth Customer identity platform offering a free community edition and paid enterprise options. Free community edition; paid plans for enterprise features and support. OAuth2, OIDC, SAML support; self-hosting for full control. Moderate; requires setup but provides good documentation. High; built to handle millions of users. GDPR, CCPA, HIPAA (with enterprise edition). High; extensive customization when self-hosted. Yes (Google, Facebook, Twitter, LinkedIn, GitHub, Apple, Amazon, Steam, and others)
AWS Cognito Amazon’s solution for user sign-up, sign-in, and access control. Free tier; pay-as-you-go based on MAUs and features used. Email/password, social logins, MFA; integrates with AWS services. Complex; may require AWS expertise. High; scalable on AWS infrastructure. HIPAA eligible; aligns with AWS compliance programs. Moderate; customization possible but complex. Yes (Google, Facebook, Amazon, Apple, and any OpenID Connect or SAML 2.0 identity provider)
SuperTokens Open-source authentication focusing on security and user experience. Core features are free; paid for managed services and enterprise features. Email/password, social logins, passwordless; self-hosting option. Moderate; developer-friendly but requires setup. High; scalable when self-hosted. Self-managed compliance responsibilities. High; full control with open-source code. Yes (Google, Facebook, Apple, GitHub; extendable with custom providers)
Keycloak Open-source identity and access management solution for enterprise applications. Free; fully open-source and self-hosted. SSO, social login, identity brokering; extensive features. Complex; requires technical expertise to deploy and maintain. High; depends on your hosting infrastructure. Self-managed; compliance depends on your setup. Very high; highly customizable but complex. Yes (Supports any OpenID Connect or SAML 2.0 providers, including Google, Facebook, Twitter, GitHub, LinkedIn, Microsoft, and more)

Go build value, not login flows

If you reached this point we hope you understand the big picture when it comes to user authentication and how to get it done. It’s a complicated topic and only you know what your requirements are. Between our basic advice and that table of AaaS service providers up there we hope we gave you a good start on narrowing down your decision on who to go with.

 

If you need more details or want to talk more about building out a digital platform on modern standards we love talking about this stuff. Get in touch.

 

37 questions you should ask your developers about app security

In an earlier article we talked about threat intelligence and securing your code against hackers from the start. That article focused on applying a subset of OWASP guidelines to web applications and backends. In this article we are going to do something similar for mobile apps.

We’re going to give you an overview of OWASP’s mobile application security guidelines using example apps and giving you questions you can ask your developers to work out how secure your app is.

Security is paramount for mobile apps. Unlike your backend servers, you can assume your mobile app is in the hands of bad actors. And if it is not, it might be sharing a phone with malware that would love to extract any useful personal or financial information your app might collect.

Let’s start with the example apps. They were “designed” to have different requirements, but they all share best practices for security.

Our Three Imaginary Mobile Apps:

(Any resemblance to existing apps or apps with the same name is purely coincidental. Naming is hard.)

Introducing the OWASP MASVS (Mobile Application Security Verification Standard)

The OWASP MASVS is divided into 8 groups:

  1. MASVS-STORAGE: Secure storage of sensitive data on a device (data-at-rest).
  2. MASVS-CRYPTO: Cryptographic functionality used to protect sensitive data.
  3. MASVS-AUTH: Authentication and authorization mechanisms used by the mobile app.
  4. MASVS-NETWORK: Secure network communication between the mobile app and remote endpoints (data-in-transit).
  5. MASVS-PLATFORM: Secure interaction with the underlying mobile platform and other installed apps.
  6. MASVS-CODE: Security best practices for data processing and keeping the app up-to-date.
  7. MASVS-RESILIENCE: Resilience to reverse engineering and tampering attempts.
  8. MASVS-PRIVACY: Privacy controls to protect user privacy.

Let’s go through them quickly, covering what you should be concerned about and what to ask your developers to confirm it is being addressed.

MASVS-STORAGE: Secure Data Storage

The most secure data is the data you never store. The second most secure data is data that you don’t store on a device you don’t control. Always ask if it’s necessary to store the data, and if you have to store it, what is the most secure option. 

Everyone wants to store credit card data because it makes purchase UX so much smoother. But no-one wants to become a target for hackers who love extracting thousands of active, verified credit cards. 

The same goes for personal information.

How the apps might approach compliance:

Questions to Guide Decision Making:

  1. What types of user data will our app store on the device?
  2. Is any sensitive personal or financial information being stored locally?
  3. How are we protecting stored data against unauthorized access?
  4. Can we minimise local storage by keeping data on secure servers?
  5. Are there scenarios where storing data locally is unavoidable? If so, what system APIs or third party libraries are we using to provide secure storage?

MASVS-CRYPTO: Secure Use of Cryptography

You need to use up-to-date, strong encryption methods to protect data both when stored and during transmission, and manage encryption keys securely. This is not a situation where you can build your own solution. 

How the apps might approach compliance:

Questions to guide decision making:

  1. Are we using industry-standard encryption methods to protect data?
  2. How are we securely managing and storing encryption keys?
  3. Is all sensitive data encrypted during network transmission?
  4. Do we need to encrypt data stored locally on user devices?

MASVS-AUTH: Secure Authentication and Authorization

Implementing secure methods for user login and verifying that users have permission to perform certain actions within the app is critical. On both iOS and Android, secure authentication can be implemented using standard protocols like OAuth 2.0 and leveraging platform features for handling credentials securely. Both platforms support biometric authentication (like Touch ID and Face ID on iOS, and Fingerprint or Facial Recognition on Android) through secure APIs.

How the apps might approach compliance:

Questions to guide decision making:

  1. How will users authenticate within the app?
  2. Do we need additional authentication steps for sensitive actions?
  3. Are we using secure protocols for handling authentication data?
  4. Do different user roles require different levels of access?
  5. Should we implement multi-factor authentication for added security?

MASVS-NETWORK: Secure Network Communication

This should now be a given. Though you can make an argument that if your app relies on a large volume of static media, architecting your backend to deliver media via dedicated servers (or cloud services like Amazon S3) using a simpler unsecured protocol like HTTP can provide a small reduction in management overhead.

But, it is better to just have all track use secure network protocols like HTTPS/TLS. Both iOS and Android support SSL/TLS pinning if necessary and provide networking libraries that handle security appropriately.

How the apps might approach compliance:

Questions to guide decision making:

  1. Are all network communications encrypted using HTTPS/TLS?
  2. Have we ensured that there are no insecure connections within the app?
  3. Do we need to verify the identity of servers we communicate with beyond standard measures?
  4. Are there any additional steps we should take to secure data transmission?

MASVS-PLATFORM: Secure Interaction with the Mobile Platform

Your app needs to safely interact with the device’s operating system and other apps, ensuring features like notifications and data sharing don’t expose sensitive information. On both iOS and Android, there are guidelines and APIs for secure inter-process communication (IPC), handling intents (Android), or URL schemes (iOS), and configuring notifications to protect sensitive data.

How the apps might approach compliance:

Questions to guide decision making:

  1. Does our app expose any functionality or data to other apps?
  2. Are we securely handling features like notifications and data sharing?
  3. Could sensitive information be unintentionally exposed through the user interface?
  4. Do we need to limit access to certain device features or permissions?
  5. Are there platform-specific security considerations we need to address?

MASVS-CODE: Code Quality and Security

It’s important to ensure that your app’s code is free from common vulnerabilities, follows secure coding practices, and stays updated with security patches. On both iOS and Android, this involves using secure coding standards, conducting regular code reviews, and keeping third-party libraries up to date. We covered some of the tools for this in the article on verifying the third party code your app will use.

How the apps might approach compliance:

Questions to guide decision making:

  1. Are we following secure coding best practices throughout development?
  2. Have we validated and sanitised all user inputs and external data?
  3. Are all software libraries and components up to date and free from known vulnerabilities?
  4. Do we have a process in place to quickly update the app and patch security issues?
  5. Are we enforcing a minimum platform version to ensure necessary security features are available?

MASVS-RESILIENCE: Protecting Against Reverse Engineering and Tampering

This is a challenging part of the security stack. It is in reality impossible to stop this from happening. This means you need to ask yourself – what would a hacker gain by having access to the source code of your app?

Every other group in the OWASP MASVS has a role in protecting your business from this situation. This is why data storage choices are important, and why authentication is essential.

There are companies out there offering solutions which obfuscate code, and platforms like iOS try to block access to your app’s code, but there are also companies offering tools to counter these protections. 

How the apps might approach compliance:

Questions to guide decision making:

  1. Do we need to protect proprietary code or sensitive algorithms within the app?
  2. Are there risks if the app is reverse-engineered or tampered with?
  3. Should we implement code obfuscation or other anti-tampering measures?
  4. Are we considering the security of the app on compromised devices?

MASVS-PRIVACY: Ensuring User Privacy

Your app needs to collect and use user data responsibly. You should strive to minimise data collection, and provide transparency and control to users over their personal information. Both iOS and Android have guidelines and requirements for privacy, such as the App Privacy Details in the App Store and the Google Play Data safety section. Compliance involves adhering to these guidelines and any applicable data protection regulations like GDPR.

How the apps might approach compliance:

Questions to guide decision making:

  1. What user data are we collecting, and is each data point necessary for app functionality?
  2. Are we transparent with users about our data collection and usage practices?
  3. Do we provide users with control over their data, such as options to delete or modify it?
  4. Are we compliant with relevant privacy laws and regulations in our operating regions?
  5. How are we ensuring that user data isn’t shared with third parties without explicit consent?

Mobile app security is a headache

Building a secure mobile app is one of those “the devil is in the details” pursuits. But it needs to be done.

For experienced app developers most of the OWASP MASVS is simply how it’s done. But there are strategic decisions to be made, particularly around data – its collection, its storage and its transmission.

Hopefully this guide has given you an actionable top level understanding of mobile app security and provided you with the questions you need to be asking to make sure your app is locked down on launch day.

There are always more details and more questions. If you have any questions feel free to get in touch. We’d be happy to answer them.

Beat hackers and protect your business before running a single line of code

Hackers are getting out of hand. We’re sure you’ve noticed. Ignoring self-owns like the recent CrowdStrike debacle making the news, we seem to hear about new zero-day, zero-click exploits on a daily basis. Software infrastructure is complex and this complexity makes it vulnerable to bad actors. 

Bad actors that are willing to put in months of effort to convince developers to give them access to code so they can install backdoors that will let them take over every Linux server.

What can you do when your business is built on a technology platform constructed from thousands of open source and third party libraries containing millions of lines of code that your team didn’t write?

And what can you do when every new service you launch, like the API gateway your app and website will talk to, is discovered and scanned for vulnerabilities within an hour of going live? And not just once, but continuously by automated tools run by multiple anonymous parties? 

Keeping your platform secure sounds daunting when spelled out like that. 

But there is a way forward, and it involves integrating threat intelligence into your development process from the very beginning. Before your developers write the first line of code, and before they start installing the libraries your technology platform is going to be built on.

Threat intelligence is applying knowledge of the tools and techniques bad actors use to breach security. It  can be used at every point in the architecture and lifecycle of your platform. This makes it a huge topic and one that keeps shifting as new techniques and counter-measures are put into play. 

It’s too huge a topic for a single article, so we’re just going to look at the first step – building your platform – and only one facet of that: vetting open source and third party code. 

We’re going to give you an overview of the easiest to use tools available for incorporating this essential process. 

But first we’re going to talk about the OWASP Top Ten and where this vetting of code sits on the list. 

The OWASP Top Ten and secure coding practices

The OWASP Top Ten is a list of the 10 most critical security risks to web applications. It’s compiled by OWASP (the Open Worldwide Application Security Project – a nonprofit foundation) in consultation with its membership of cybersecurity professionals. 

The OWASP Top Ten list is due to be updated in early 2025, but here are the risks from the current 2021 version of the list:

We’re discussing “web applications” throughout this article because current practices are to build a web-based backend that both apps and websites frontends talk to on behalf of users. OWASP also has security recommendations for mobile apps you can read here, but we’re not going to talk about that in this article.

As we said earlier, this article is going to focus on just one item from the OWASP Top Ten – “Vulnerable and Outdated Components”. And we are going to focus on this security risk because there are services that can help you manage it. They’re not “set and forget”, but they don’t require in-depth training or expertise in order to adopt them and get immediate benefit from them.

They augment the role of the “Software Security Engineer” and automate the process of researching vulnerabilities that used to be done by googling or searching through the NIST National Vulnerability Database (NVD).

Some services, like Snyk, have their own security researchers to discover vulnerabilities and develop mitigations for them (like patches or updates for the troublesome library) and also contribute those vulnerabilities back to the NVD.

Snyk

Snyk call themselves “The developer security company” and they offer a suite of tools and services for mitigating supply chain attacks. 

These tools include Snyk Open Source. This performs source code analysis to find vulnerable dependencies. It integrates with your developers’ IDE, can scan pull requests, and can be integrated into your CI/CD pipeline to check no new vulnerabilities make it into production. 

They also provide continuous monitoring so if new vulnerabilities are discovered you can move quickly to address them. 

Snyk can be used for free by individual developers and small teams, with some limitations on testing and with no Jira integration. 

GitHub  

If you’re already using GitHub for hosting your code or planning to, it makes sense to take advantage of its built-in security features. GitHub’s Dependabot automatically scans your dependencies for vulnerabilities and raises pull requests to update them, similar to Snyk’s open-source scanning, but without the need for additional setup.

GitHub Advanced Security goes further with features like secret scanning and code scanning, catching issues early, even before code is pushed. While Snyk also offers these kinds of tools, GitHub’s advantage is that everything is built right into the platform you’re already using for version control. 

GitLab 

GitLab, GitHub’s open-source competitor, also offers a suite of security features designed to fit smoothly into your development pipeline. If you’re already using GitLab for CI/CD or planning to, its built-in security tools can save you time and effort by automatically integrating into your workflows.

Like Snyk, GitLab includes dependency scanning, checking your code for vulnerabilities in open-source libraries and suggesting fixes with merge requests. GitLab also offers security features like container scanning, static application security testing (SAST), and dynamic application security testing (DAST), all built into the platform. This gives it an edge for teams already leveraging GitLab’s DevOps capabilities, as you get a unified toolset for both development and security without needing to add third-party integrations.

There are 65 different service providers for this kind of service (Software Composition Analysis) on G2. Way too many to go through without wasting your time, but between Snyk, Github, and GitLab you have three options your developers can try integrating into your development process today. 

Trust but verify the libraries you rely on

We’re all building on the shoulders of giants out here. Not-invented-here syndrome needs to give way to the demands of time-to-market, which means open source libraries, which includes entire ecosystems like React, Node, and Laravel as well as server operating systems (Linux), web servers, and the proliferation of databases.

You are going to use third party code so make the decision now to mitigate the risks of bad actors, bad design decisions, and changing technology that necessity will expose you to.

Get your developers on board with one of the options we’ve talked about, or go spend a couple weeks talking to each of the vendors on G2’s list, Just make sure you have a solution in place before you start running code.

Property Management Systems – Pick your niche and grow

Property Management Systems – Pick your niche and grow 

There are thousands of Property management systems (PMS) aka real estate management systems/software/solutions. And the reason there are so many is simply because the property market is incredibly rich and diverse. 

There are different geographic areas, different types of property, different types of tenants, different types of property owners, different types of property managers and property management businesses. 

It is an industry of niches. And there are providers out there struggling to supply a one-size-fits-all solution to property management, but you can’t do everything well and you can’t do everything simply and you can’t do everything while supplying an enticing (and true) value proposition to everyone.

This means there are always numerous under-served, unsatisfied market segments looking for a property management system that gets them. That fits their needs.

You’re probably part of one of those segments, part of a niche that available solutions fall short or completely miss to create some value for or at the very least offer some efficiencies to ease the workload.

That deep knowledge of a property management niche is a huge advantage and is the foundation for building a successful PMS that might begin with a theoretically small market, but in practice has no upper bound on growth. 

Let’s start with some background on PMSs.

What Are Property Management Systems?

Property Management Systems are software solutions that automate the various tasks associated with the management of real estate properties.

Depending on their focus (or lack of focus), they can cover areas like property listings, tenant management, rent collection, financial tracking, maintenance scheduling, reporting, and more.

The obvious benefits of Property Management Systems:

The primary purpose of PMSs is to make executing on the often complex processes of property management easier, thus lowering barriers to success and also lowering the level of expertise needed, which provides a secondary benefit of making the filling of property management roles easier. 

Ease of use goes hand-in-hand with efficiency. A good PMS makes the difficult simple and the tiresome painless. A good PMS doesn’t just do this for the back office processes. A good PMS makes all interactions easier and provides a better experience for everyone that has to interact with the PMS, including property owners, tenants, service providers (plumbers, locksmiths, etc), while enhancing the overall experience for property owners and tenants. 

On top of process improvement, a PMS gives stakeholders access to detailed analytics covering every aspect of the processes and transactions it implements. These are the essential numbers for running a property management business and another key reason for adopting a PMS. 

For the PMS platform owner, which could be you, access to anonymised and/or aggregated data provides opportunities for targeting development towards the features analytics reveal your users rely on the most in order to increase market appeal, but it can also provide market insights that are unavailable elsewhere and present a true advantage. 

How Property Management Systems are aggregating new technologies

The first PMS was a ledger – a physical book with pages of properties and related transactions filled out by hand. There were probably some ledger hold-outs up into the 90s, everyone else having moved to PC-based options in the 80s.

The real driver for uptake (and building) of PMSs was the development of payment service integrations, allowing even the smallest player to use a PMS to set up direct debits for tenants. This in turn has driven the development of countless PMSs because venture capital loves nothing better than business models that place themselves in the middle of a high number of financial transactions that they can take a 3%-5% fee from.

Today PMSs are SaaS – Software as a Service – running in the cloud, with a website designed to be mobile-first, with market leaders also offering native IOS and Android apps.

But a PMS can also extend beyond the browser, the desktop and the phone, depending on the niche. The proliferation of cheap microcontrollers with sensors plus connectivity via WiFi or 4/5G has created a revolution. It’s the Internet of Things (IoT) and it makes detailed property monitoring for maintenance and security cheap and accessible. For PMSs with feature sets that lean towards maintaining properties, integration with IoT networks, providing automated monitoring as well as analytics to generate predictive maintenance schedules and live feeds of property condition is a must-have.   

And we can’t talk about technology without mentioning AI and its use in PMSs. This can be generative AI (think ChatGPT) for helping with the production of property listings and other written communication, and customer service in the form of chatbots. It can also be Predictive AI that ingests the data collected by your PMS and generates maintenance schedules, flags tenant issues early, etc. You can read more about Generative and Predictive AI in this article.  

Picking the niche for your Property Management System

Ideally you should already have the niche for your PMS picked out. The best niche is the one that you have experience in and understand the challenges and pain points that participants (like yourself) need to be addressed firsthand.

If you’re not sure about a niche, below is a list to get you thinking. We’ll leave it up to you to decide if you want to target a market of mice, rabbits, deer or elephants (there are no flies in real estate). 

What features your PMS will need depends on your niche. What features the MVP version of your PMS will launch with depends on how well you understand your chosen market.

Build your own Property Management System or tailor an existing one?

PMSs have been around long enough that there are not only software development houses with deep expertise in building them, but there are also software houses that offer white label solutions – prebuilt software you can check off the features you want and slap your branding on and launch. 

This makes one of your first and biggest decisions on launching a PMS a choice between build or buy. 

Build gives you control. That control gives you a straightforward path towards growth.

Buy gives you speed, but very little control. There are a multitude of options for how you purchase and run a white label PMS. They all have trade-offs and we don’t have the space to go through them. If you take this path, do your homework to ensure you have clear lines for growth, preferably via access to the PMS’s source code (which you hope is high quality) and accessible expertise to keep it running and build upon it.

Build vs buy is a chicken and egg gamble. 

Does buying and launching quickly let you confirm the market is there or will the market be uninterested in your copycat PMS?     

Does building let you launch with a product tailored to your market months later or do you burn cash and time to release a new PMS the market is uninterested in? (Hint: you can reduce the chances of the second option by checking out the LEAN canvas methodology and how to find product-market fit.)

But business is always a gamble, but it’s one of the few gambles where working hard and working smart can vastly improve your odds.

Property Management Systems are software and software is malleable

That sounds deep. But what it means is that once your PMS is successfully servicing its niche you are now the proud owner of a machine that makes money and that machine takes very little (comparative) effort to retarget or to expand.

The hard part is finding and landing that first niche. Once you grind out success in a niche you have in place 80+% of what you need to take over the next niche. Or to grow up out of your niche into the broader market – from regional unit rentals to regional residential rentals to nationwide residential rentals. Why not go global from there?  

Pick your Property Management System developer and grow

This is the pitch. SoftwareSeni gets proptech. We build proptech. We’ve been building software based businesses in the real estate market for nearly 15 years. We build businesses from the ground up and for many of them we also manage the backend, keeping them running and secure and profitable.  

We’ve been helping businesses start and grow for long enough that we don’t just have the technical knowledge you need, we’ve got the business experience to help you gain the maximum leverage from our technical knowledge.

If you have a niche you want to build a PMS for, or just want to talk proptech, get in touch with us. 

How to spot opportunities in your business to use AI

Before we go over the 5 main interfaces where AI might help your business, let’s talk about the two kinds of AI.

The two kinds of AI – Generative and Predictive

Generative AI is the AI like ChatGPT, Claude and Gemini that everyone has been excited about for the last year/18 months. They are Large Language Models (LLMs). They’ve been trained on a vast amount of text (web pages, books, video and podcast transcripts, etc) and they work by being fed text in, like a question, and they output text in response. They are specialised for working with text and so human languages. They are bad at working with numerical data.

Predictive AI is what we used to think of as AI – neural networks, crunching lots of numbers, and making predictions like which customer is going to miss a credit card payment. 

Both Generative AI and Predictive AI are built using the same principles and same key software components, but they have different purposes.

For this article we are going to only look at Generative AI.

Now back to business and where to implement Generative AI, which we’re going to call Gen AI for the rest of the article to save on typing.

Where your customers reach out to your people

Where your customers reach out to your people

This is already one of the most popular points to use Gen AI. This is where chatbots live. The reason to implement Gen AI is because you want to either reduce resources or increase opportunities to provide information to current and potential customers.

It’s also where you can use Gen AI to implement smart filtering or triage of customers looking to buy or looking for support.

And it’s where you can use Gen AI to streamline information gathering on customers through conversational style interfaces that can better handle the trickiness of talking to people while providing a better experience than a lengthy form.

Here are 3 solutions you can try today:

Where your people reach out to your customers

Where your people reach out to your customers

This interface is predominantly sales and marketing related:

Imagine never again sending an auto-response email that says “Do not respond to this email”, but instead turning email into a new “chat interface” for your customers to interact with your business.

Try these 3 targeted products for outbound customer engagement:

Where your customers interface with your business systems

Where your customers interface with your business systems

We hinted at this above in the “email as chatbot interface” line. But this interface covers opportunities for using Gen AI for:

Here are 3 AI tools to enhance system interfaces:

Inhouse – Between your people

Inhouse - Between your people

This interface is full of opportunities and possibilities for growth, flexibility and efficiency. Doing a deep-dive on how your business functions and where expertise sits in your processes will uncover lots of places where you can:

Check out these 3 internal support tools:

Inhouse – Between your people and your systems

Inhouse - Between your people and your systems

Here is where your people are working with existing inhouse and third party systems. Gen AI can be used to boost quality of execution and, depending on the process, also reduce the time spent. 

The kind of processes that Gen AI can be applied to at this interface include:

Check out these solutions designed to bridge the chasm between complex systems and processes and your team:

The 3 major Gen AI approaches

Across the 5 major interfaces we covered, all the options to apply Gen AI are covered by only 3 approaches:

  1. Automate/Augment an interaction
  2. Automate/Augment the process of an interaction 
  3. Automate the artefacts an interaction produces (meeting notes, contracts, sales orders, product configurations, etc.)

When you’re looking at implementing Gen AI to support or automate an interaction or process, these are the three opportunities you should be looking for at each step.

Getting started implementing Gen AI

Implementing Gen AI in your business can start small. Process support is a great place. After chatbots, the key tool in Gen AI is called RAG – Retrieval Augmented Generation. This is often marketed as “Chat with your documents”. 

You can use RAG to give access to knowledge that might be in your SOPs (presuming these are in Word docs, Google Drive or similar) or in your product manuals or in years of client emails.

NotebookLM is Google’s version of this if you want to try it with a test case. Both OpenAI and Anthropic let you upload documents in their chat interfaces and ask questions about them.

A step beyond “Chat with your documents” is creating workflows that incorporate Gen AI. Dify.ai is a good place to start with this. It has a simple visual interface and it lets you easily build RAG-based chatbots that you can embed in your website if you want to try that approach. It has lots of other features and applications worth investigating.

For more advanced workflows there is n8n, and the incumbent workflow automation services – Make and Zapier – also offer Gen AI features.  

Don’t wait to start using AI

We hope this short guide has given you the necessary guidance on how to look at your business and how to look at your processes to find where you can take advantage of Generative AI. 

Doing is understanding. So start small – add Gen AI to a single step in a single process – and grow out from there. We find the more you use Gen AI, the more you find ways to use Gen AI.

If you’ve got any questions about AI or how you can implement it in your business, or just want to talk through strategies and opportunities, get in contact.

Why we all should want Junior Devs working smarter more than Senior Devs working faster

AI is having a huge impact on software development. Even a year ago McKinsey did empirical research that showed AI coding tools were giving a 30-50% speed up for developers. Now, with Github Copilot being joined by tools like Cursor, aider and Zed, which push developer support from fancy auto-complete to hands-free multi-file edits, it feels like software development is about to undergo another leap in speed of execution.

As Charity Major discusses in an article on StackOverflow, this increase in developer efficiency is leading industry executives and thought leaders to believe that “generative AI is on the verge of replacing all the work done by junior engineers”. 

She has about 5000 very smart words on why that’s wrong. We’re going to cover the same ground in a few hundred words and tell you what we’re doing about the situation.

The coding is the easy part

Businesses run on software. Most businesses are software. Writing that software is not the hard part about being a business made of software. The problem is complexity.

Yes, software is complex. But the real complexity is in the system that the software needs to exist in. This system isn’t limited to the boundaries of your organisation. It includes the infrastructure your software runs on, the other software it interacts with, and the pieces, the libraries, of software it is built from. The recent Crowdstrike related outage is an example of the complexity of the current system all software operates within.

Managing that complexity, and managing complexity in general, is the real skill and the real value that software developers deliver. And it takes time to learn it. Programming can be taught in a school or learned from a book. But mastering the details of the huge number of systems that are at play in the modern tech stack, where idiosyncrasies abound (because reality is imperfect and unpredictable), and unknown unknowns are numerous, takes years and requires mentorship. 

As Charity Major says, this means we have to recognise that software development is an apprenticeship. Junior developers don’t become senior developers on their own. There is too much craft, too much knowledge learned through experience, too many mistakes to make, for a junior developer to master it all in a reasonable amount of time without guidance.

AI should empower junior developers, not replace them

The argument for not hiring junior developers is centred on the idea that why add to your headcount with a junior developer when you can just give a senior developer some AI coding tools.

As we wrote in our article on harnessing AI to save your business from the future:

“if your revenue per employee keeps going up as they complete work faster and do more using AI, why would you fire anyone?”

This situation is more of a “if your employees do more using AI why would you not let them do more?” situation.

If AI can help your senior developers do more senior developing – architecture, strategy, planning – why would you make your senior developers use AI to do junior developer work?

Junior developer work does involve writing code, under the direction of and with reviews by senior developers. But junior developers are also the go-to for writing test cases and refactoring code. This helps them build familiarity with your codebase and engages them with reading and understanding code written by experienced developers.

And if it is an AI coding tool that is writing the tests and refactoring the code, it should still be a junior developer driving it. The benefits are the same for the developer but the cost to you, which is accompanied by an opportunity cost, is lower. Having a senior developer generating tests instead of working on your overall system design, architecture or key features is not just throwing away money, it’s throwing away time.

Without junior developers there will be no senior developers

Every senior developer started as a junior developer. They spent the 5-7 years learning the craft of software development under more experienced programmers. 

No-one has suggested that the world needs fewer senior developers. They are what every business wants to hire. 

But the execs and “thought leaders” who think junior developers are moments away from being automated out of existence haven’t explained where new senior developers are going to spring from.

They are not going to be created by AI coding tools.

This image is currently making the rounds in the tech-sphere:

If you know, you know. If you don’t know, consider it a taste of the complexities of software. We like to think that Blue Bubble next took the time to explain to Grey Bubble what they were misunderstanding and gave them some paths towards being able to share their creation. A little bit of mentoring, if you will.

We’ll keep growing junior developers into senior developers

In an earlier article we wrote about Core+ teams. A Core+ team is your core in-house team at the heart of an on-demand team that changes in size and structure to meet the latest challenge. 

It’s the future for lean, flexible business. And it relies on companies like SoftwareSeni cultivating and supporting a large pool of talented software developers. We’re a company of software developers focused on developing software. It’s no surprise developers like working here.

We build our pool by hiring experienced developers who want to work with us and by hiring graduates straight out of university. We invest substantial training in all of our developers because their skill and their well being is the foundation for our success.

It’s what we’ve been doing for over a decade now. We’re practised at growing junior developers into senior developers. And we’re experts at helping businesses build the optimal mix of skills in their Core+ team to suit their product, their budget, and their velocity.

And a team of all senior developers doesn’t make operational or budgetary sense. No matter how many AI-powered tools you give them.

There will always be a place for junior developers

You don’t have to be a genius to see that the idea that the days of junior developers are numbered doesn’t make sense. Not in a world that continues to grow more complicated and the skills to deal with it are quicker to teach than to discover.

And there will always be a place for junior developers at SoftwareSeni. They’re an essential part of our team and our future. They’re also an essential part of our clients’ teams and what they are able to achieve given the tough constraints everyone is working under at the moment.