Customization is not always the answer
This fits like
You do an action often, by hand and always in the same way
The same data is in two systems and differs
Existing apps or plug-ins only cover part of it, and you solve the rest with workarounds
The process belongs to your company and does not change every month
This fits less well than
There is a feature or app that solves the problem well enough
This is something that happens a few times a year
The process is not yet fixed and is constantly changing
After delivery, there is no room for maintenance, in time or budget
Customization is not suitable, then we look for the existing function or app that comes closest and help you set it up. Sometimes the outcome is that nothing needs to be built.
We weigh an existing app and customization on five points
An existing app is faster to use, customization fits better. Which of the two is wiser depends on these points.
Costs, now and per year
An existing app usually costs a subscription, customization mainly costs a construction amount plus maintenance. We compare both over a period of a few years; the first month says little.
Maintenance
An existing app is maintained by the creator, at his pace and with his choices. You maintain custom work yourself or through us, as agreed.
Security
Every app that can access your data is one more party you have to trust. We look at what access an app requires and whether it suits what it does.
Dependencies
If the maker stops, the price changes or a function disappears, you have little influence on this. Customization in turn depends on the systems to which it is linked.
Ease of management
Who will work with it, and how much does that person have to learn? An app that fits your process exactly is sometimes easier to use than an existing app with many settings that you do not need.
First the process, then the code
Understanding the process.We will walk you through how things are going: who does what, in which system, how often and where things get stuck. Preferably based on real cases, such as an order or request from last week.
Assess existing solutions.We find out whether a feature, app or plug-in already solves the problem, and what it costs and limits. If there is, we will recommend it.
Defining requirements.We record what the app should do and what not, what data goes into it, who gets what rights and what happens if something goes wrong. That is the basis for the proposal.
Prototype.A first version with sample data so you can see and try how it works before anything hangs on your real systems. Anything that is not correct can be quickly corrected here.
Build.We build the app and the integrations, where possible, first against a test environment or test data, so that nothing ends up in your real administration.
Integration test.An integration test checks whether the app works together with the other systems, rather than whether it works separately. What happens if there is a missing field, a double entry or a system that does not respond for a while? You test with your own cases.
Transfer.The app goes live with a description of what it does, which accounts and keys are associated with it, where you see errors and who does what in the event of a malfunction. We make a separate appointment for maintenance and further development.
Five topics that are on the table before we build
These points determine how the app is put together and what it will cost after delivery. That is why we discuss them in advance and not halfway through.
Roll
Who uses the app, and does everyone do the same? An employee who processes orders needs different screens than someone who manages prices or a customer who only sees their own data.
Access rights
Which data can the app read and which can it change? We do not request more access than necessary, and you will see in advance which one that is. You give access via your own account or key that you can revoke yourself, never by sharing a password.
Error handling
What happens if a link doesn’t go through or someone enters something incomplete? We agree who will receive a notification, where you can see what went wrong and how you can fix it.
Maintenance
The software surrounding the app changes: platforms receive updates and APIs receive new versions. Maintenance means keeping track of those updates, checking whether everything still works together, repairing what breaks and further developing the app as agreed.
Recurring costs
After construction, costs continue, such as hosting, subscriptions for linked software and maintenance. These are shown next to the proposal, so that you can see what the app costs per year, in addition to what it costs to build it.
What we need for a proposal
A proposal for customization is as precise as the image of your process. This helps the most:
A description of the action or problem, in your own words
A few real examples, such as an order, quotation or request; You may omit personal data
What software is involved, with the name and the subscription you have
Who will use the app and how often
What you’ve already tried, such as existing apps or plugins
Only during construction: access via your own account or key, never via a shared password
Where the costs of an app come from
We do not mention amounts here. After defining the requirements, the price of the construction is written down, with the recurring costs next to it.
Scope.The number of screens, steps and exceptions. An exception that occurs once a month also needs to be built and tested.
Links.How many systems the app talks to, in which direction, and how well the API of those systems is described.
Roles and rights.One type of user is simpler than customers, employees and administrators who are each allowed to do something different.
Data migration.Existing data that needs to be cleaned and transferred before the app can work with it.
Design.How many screens need their own design and whether the app should fit into the layout of your existing site.
Testing.The number of situations that need to be tested, and whether a test environment for the linked software is available.
Recurring costs
Hosting of the app and any database
Subscriptions or API costs of associated software
Licenses of parts or services used
Maintenance: updates, compatibility checking and recovery
Further development, if you want to add functions later
Questions about customization
Do I need to replace my current software?
Usually not. An app or link builds on the software you already use. Only if a system does not allow a integration and that is the core of the problem, we discuss an alternative.
What happens to the data that the app processes?
This often concerns customer or order data. We agree on what data is needed, where it is stored, who can access it and how long it will be kept. It doesn’t store anything the app doesn’t need.
Can I adjust something in the app myself?
We can make settings that change frequently, such as prices, options or texts, manageable. What the app does and how it calculates changes through an adjustment in the code.
Can the app grow later?
We first build the smallest version that solves the problem, and write down which extensions make sense. This way the first version remains clear and you know which step can be taken next. We will agree on further development separately.
What if an existing package can do it later?
Then we look again, and sometimes switching is the best choice. That is why we record which data the app stores and in what form, so that a switch does not get stuck with data that is only in the app.
Who will own the app when it’s finished?
We determine this in advance: who owns the code, whose account the app and hosting are on, and what you get if you continue with someone else later.
Customization within Shopify, or first a online shop
Have a Shopify app made. A function within your Shopify management or your checkout requires different choices: custom or public, permissions, and what depends on your subscription.
Have a online shop created. Don’t have a online shop yet, or have doubts about the platform? Start there.
