Nova Shift Tech

Blog

  • Custom software: questions to ask before you invest

    Skip to content
    FRDiscuss Your Project

    Home / Insights

    Custom software

    Custom software: questions to ask before you invest

    Before starting a build, clarify the problem, the existing alternatives, the total cost and your ability to keep the solution alive.

    Custom software can transform the way a business operates. It can also become an expensive burden if it is started without the right questions. Here are the ones we recommend asking before you invest.

    What problem are we really trying to solve?

    “We need an app” is not a problem — it is a solution. Describe the current situation instead: who does what, with which tools, and where time is lost, errors happen or frustration builds. A well-stated problem naturally points towards the right solution.

    Is there already an off-the-shelf option?

    Before building, check whether existing software, possibly configured, could cover most of the need. Custom development makes sense when your processes are genuinely specific, when they are a competitive advantage, or when standard tools force too many compromises.

    What is the total cost, not just the initial one?

    Building the first version is only part of the investment. Hosting, maintenance, security updates, user support and future changes all add up. Thinking in total cost over several years avoids unpleasant surprises.

    Who will keep it alive?

    Software needs a business owner who can prioritise changes and speak for its users. On the technical side, make sure the code, documentation and access rights would let you change supplier if you ever needed to.

    How can we deliver value quickly?

    Instead of a months-long project delivered in one go, aim for a first version focused on the most important use case. It lets you validate assumptions, gather real feedback and adjust what comes next.

    What does it need to talk to?

    CRM, accounting, email, payments: isolated software creates new double entry. Integrations should be identified during scoping because they strongly influence architecture and budget.

    In short

    A good custom software project starts with a clear problem, an honest comparison with alternatives and a realistic view of long-term cost. That preparation is often what separates a tool people adopt from one they abandon.

    This article offers general guidance and does not replace an analysis of your specific situation. All articles

    Want to discuss this for your business?

    Tell us about your context and we’ll help you see things more clearly.

    Discuss Your Project

  • How Salesforce can support your business processes and customer relationships

    Skip to content
    FRDiscuss Your Project

    Home / Insights

    Salesforce

    How Salesforce can support your business processes and customer relationships

    A CRM is only useful if it reflects how you actually work. The principles for turning it into a real management tool.

    Salesforce is usually described as a CRM — a customer relationship management tool. In practice it is a platform on which you can model much of how an organisation works. The key is configuring it around what actually happens on the ground.

    Start from processes, not features

    It is tempting to switch on everything the platform offers. A better approach is to describe your key processes first — from prospecting to account management, from incoming request to resolution — and then configure the tool to serve them. Unused features clutter the interface and slow adoption.

    A clear data model

    Accounts, contacts, opportunities, cases: the way information is structured determines the quality of the reporting you will get. A simple, consistent data model beats a sprawl of fields added one request at a time.

    Automate repetitive work

    Follow-ups, assignments, notifications, approvals: Salesforce’s automation tools can remove a good share of manual work. Each automation should still be documented and tested, because too many of them can make the system hard to understand.

    Connect Salesforce to your other tools

    Website, email marketing, payments or ERP: a CRM becomes genuinely useful when it brings information together without re-keying. Integrations can use existing connectors or custom development through the platform’s APIs.

    Plan for adoption from day one

    A CRM is only valuable if people use it. Involve users in the design, simplify screens, train them and show what the tool does for them day to day — not just what it does for management.

    Track useful indicators

    Reports and dashboards should answer concrete questions: where do our opportunities stand? which cases are overdue? which customers haven’t we contacted recently? A few well-chosen indicators are worth more than a crowded dashboard.

    Well configured and adopted, Salesforce becomes a real tool for doing and managing the work. Poorly scoped, it becomes yet another database. Much of the difference is decided at the design stage.

    This article offers general guidance and does not replace an analysis of your specific situation. All articles

    Want to discuss this for your business?

    Tell us about your context and we’ll help you see things more clearly.

    Discuss Your Project

  • Adopting AI in business: practical considerations

    Skip to content
    FRDiscuss Your Project

    Home / Insights

    Artificial intelligence

    Adopting AI in business: practical considerations

    Use cases, data quality, confidentiality, human oversight: what to examine before deploying AI.

    Artificial intelligence generates as much excitement as concern. For a business, the question is not how to “do AI”, but where it delivers real value with risks kept under control.

    Start with a specific use case

    Successful projects start from an identified problem: triaging incoming requests, summarising documents, extracting information from forms, helping teams find internal knowledge. A precise use case lets you measure the result and adjust.

    Check data quality and availability

    AI models rely on the data you give them. Up-to-date documents, structured information and clear access rules: this groundwork determines how relevant the results will be.

    Protect confidentiality

    What data will be sent, to which service, hosted where, and with what safeguards? These questions must be settled before deployment, especially for personal, financial or strategic data.

    Keep humans in the loop

    AI systems can produce answers that sound plausible but are wrong. For sensitive uses, human review remains essential. The aim is to assist teams, not to take responsibility for decisions away from them.

    Measure before you scale

    A pilot on a limited scope shows the real gain: time saved, quality of results, user acceptance. That is the basis on which it becomes reasonable to expand.

    Train and support your teams

    AI tools change how people work. Explain what they can do, where they fall short and what good practice looks like. Informed teams use the tools better and spot errors more easily.

    Don’t overlook simpler options

    Some tasks are better solved with rule-based automation or better organisation. AI is one tool among many, to be used when it is the best fit.

    This article offers general guidance and does not replace an analysis of your specific situation. All articles

    Want to discuss this for your business?

    Tell us about your context and we’ll help you see things more clearly.

    Discuss Your Project

  • Approaching digital transformation without losing your way

    Skip to content
    FRDiscuss Your Project

    Home / Insights

    Digital transformation

    Approaching digital transformation without losing your way

    Start from real pain points, prioritise, move in steps and bring your teams along: a pragmatic approach.

    “Digital transformation” has become so common that it can lose its meaning. For a business, it is first and foremost about improving how technology supports its operations. Here is a pragmatic way to move forward without spreading yourself too thin.

    Start from real pain points

    Instead of starting with a list of technologies, ask your teams and customers: what takes too long? where do errors happen? what information is missing when decisions are made? These pain points are the best starting point.

    Take stock of what you have

    Which tools do you use, who uses them and how do they connect? A simple map of your systems often reveals duplication, double entry and fragile dependencies.

    Prioritise methodically

    Not all initiatives are equal. Assess each one on business value, cost, complexity and risk. Start with a few high-impact projects of reasonable complexity.

    Move in steps

    Big-bang transformation programmes are risky. Short stages with visible results make it possible to learn, adjust and keep teams engaged.

    Bring your teams along

    Technology transforms nothing if it isn’t adopted. Involve users from the design stage, train them and act on their feedback. Change management is part of the project, not an afterthought.

    Keep the big picture coherent

    Every new project should fit a shared direction: shared data, connected tools, consistent security rules. A roadmap that is reviewed regularly helps keep everyone on course.

    Digital transformation is not a destination but an ability to evolve your tools and practices over time. The companies that succeed are usually those that move methodically rather than hastily.

    This article offers general guidance and does not replace an analysis of your specific situation. All articles

    Want to discuss this for your business?

    Tell us about your context and we’ll help you see things more clearly.

    Discuss Your Project

  • Maintainability and integration: why they matter in software projects

    Skip to content
    FRDiscuss Your Project

    Home / Insights

    Software engineering

    Maintainability and integration: why they matter in software projects

    What makes software expensive is rarely its first version. Why maintainability and integration must be designed in from day one.

    When assessing a software project, most attention goes to what the first version will do and what it will cost. Yet most of a software product’s life happens after it goes live. Two qualities then determine its cost and usefulness: maintainability and integration.

    Maintainability is the ability to change

    Maintainable software is software you can understand, fix and modify without breaking everything. That means readable code, a clear architecture, automated tests and up-to-date documentation. These cost something upfront, but they significantly reduce the cost of every future change.

    Signs that software is hard to maintain

    • Every change causes unexpected regressions.
    • Only one person really understands how the system works.
    • Security updates are postponed for fear of breaking something.
    • Estimates for changes keep getting longer.

    Integration is the ability to work with everything else

    Isolated software forces your teams to re-enter information, export files and check consistency across systems. Well-integrated software exchanges data automatically with your CRM, accounting or business tools — reliably and traceably.

    Design integration in from the start

    Integrations bolted on later tend to be fragile. It is better to identify upfront which systems the software must talk to, what data is exchanged and how it stays in sync. Well-designed APIs also make it easier to add new tools later.

    Questions to ask your supplier

    • How is the code structured and documented?
    • Which automated tests are planned?
    • How will security updates be handled?
    • Which integrations are planned, and how will they be monitored?
    • Could another team take over the project if needed?

    Investing in maintainability and integration is investing in the lifespan of your software. It is often the difference between a tool that supports your growth and one you have to replace too soon.

    This article offers general guidance and does not replace an analysis of your specific situation. All articles

    Want to discuss this for your business?

    Tell us about your context and we’ll help you see things more clearly.

    Discuss Your Project

  • Should you automate that process? A practical assessment framework

    Skip to content
    FRDiscuss Your Project

    Home / Insights

    Automation

    Should you automate that process? A practical assessment framework

    Volume, stability, rules, risk: six simple questions to decide whether a process is worth automating — and where to start.

    “We should automate that.” It comes up in meetings all the time, usually about a task everyone finds tedious. But a tedious task is not necessarily a good candidate for automation. Before investing, a few simple questions help separate real opportunities from ideas that only look good on paper.

    1. Does the volume justify the effort?

    A ten-minute task done once a month is not the same as a two-minute task repeated fifty times a day. Estimate frequency, time spent and the number of people involved. A rough calculation is often enough to point you in the right direction.

    2. Is the process stable?

    Automating a process that changes every quarter means freezing something that isn’t mature yet. If the rules are still moving, clarify and document them first. Automation can come afterwards.

    3. Are the rules explicit?

    The clearer the rules — “if the amount exceeds this threshold, request approval” — the easier a process is to automate. When the decision relies heavily on human judgement, it is often better to assist the person than to replace them.

    4. Is the data reliable and accessible?

    An automation is only as good as the data it handles. If information is scattered, incomplete or entered inconsistently, data quality is usually the first job.

    5. What does an error cost?

    A mistake in a reminder email is not the same as a mistake in an invoice. The higher the risk, the more controls you need: human approval, logging, and alerts when something looks wrong.

    6. Who will maintain it?

    An automation is a small piece of software. It has to be documented, monitored and updated when the tools it connects change. Decide from the start who owns it.

    Where to start

    List your teams’ repetitive tasks, then rank them on two axes: how much time they take and how clear their rules are. Tasks that are both time-consuming and well defined are your best candidates. Start with one, measure the result, then expand step by step.

    And remember that automation is not always the best answer: sometimes simplifying or removing a step delivers more.

    This article offers general guidance and does not replace an analysis of your specific situation. All articles

    Want to discuss this for your business?

    Tell us about your context and we’ll help you see things more clearly.

    Discuss Your Project