Compare: hard-coding
Condexa vs hard-coding your rules
Rules engine vs hard coding comes down to one question: who changes the rule, and how long does it take? With Condexa the people who own the policy change it, test it and publish it, and your application simply asks for the answer.
Incoming request
evaluatingCan we raise the credit limit threshold today?
- If the order takes the customer over their credit limit, place it on hold.
- If any invoice is more than 45 days overdue, place it on hold.
- If the customer is on the watch list, place it on hold and flag credit control.
- Otherwise, release the order.
Answer, with the reason
Order SO-5521: on hold. The customer has an invoice 52 days overdue, which breaks the 45-day rule. Finance changes the 60 to 45 in a new version, tests it against last month's orders and publishes it. No code is touched.
Sound familiar?
Quick to write, slow to change
Putting a rule straight into application code feels sensible on day one. It is fast, it is under version control and the developer understands it. The trouble starts on day ninety, when the business wants it changed.
Every change is a dev ticket
Finance wants the approval limit moved from 5,000 to 7,500. That becomes a ticket, a sprint slot, a code review, a test cycle and a release. The policy changed in a meeting; the system catches up weeks later.
Nobody outside IT can read the rule
The real rule lives in an if statement three services deep. When the operations director asks how the system decides, someone has to go and read the code, and the answer comes back second-hand.
The same rule lives in several places
The website, the ERP customisation and the overnight job each have their own copy of the discount rule. One gets updated, the others do not, and customers get different answers depending on where they ask.
The quiet cost
What hard-coded rules quietly cost
- Developer time spent on threshold changes instead of the product.
- Policy that is already agreed but not yet live, sometimes for weeks.
- Inconsistent answers when copies of the same rule drift apart.
- An auditor asking why an order was approved, and nobody able to show the working.
Before and after
From code releases to business-owned decisions
Today
- A threshold change waits for the next release.
- The rule is readable only by developers.
- Copies of the rule drift apart across systems.
- Explaining a past decision means digging through logs and code history.
With Condexa
- The policy owner changes the value and publishes a new version the same day.
- The rule is laid out step by step on a visual canvas anyone can follow.
- Every system calls the same Active version over one API.
- Every call is recorded with its inputs, outputs and a full trace.
How you get there
How to stop hard-coding business rules with Condexa
- 1
Lift the rule out of code
Rebuild the decision on the Condexa canvas, or paste a sample JSON record and let the wizard create the shape and a starting workflow. Limits and lists go into lookup tables the business can maintain.
- 2
Prove it gives the same answers
Run it with real examples and read the trace for each one. Compare the results with what your code does today before anything changes in production.
- 3
Replace the if statements with one call
Your application calls the Active version over a REST API with an API key and gets the answer back as JSON in milliseconds. From then on, rule changes are a new version, not a new release.
A worked example
Example: an order credit hold that used to live in code
Picture a distributor whose order service has a hard-coded rule for placing orders on credit hold. Finance wants to change the overdue-days trigger from 60 to 45.
The rules, in plain English
- R1If the order takes the customer over their credit limit, place it on hold.
- R2If any invoice is more than 45 days overdue, place it on hold.
- R3If the customer is on the watch list, place it on hold and flag credit control.
- R4Otherwise, release the order.
Condexa answers
Order SO-5521: on hold. The customer has an invoice 52 days overdue, which breaks the 45-day rule. Finance changes the 60 to 45 in a new version, tests it against last month's orders and publishes it. No code is touched.
Side by side
Hard-coded rules vs Condexa, side by side
| Aspect | Hard-coded rules | Condexa |
|---|---|---|
| Who changes a rule | A developer, through the normal release process | The policy owner, with the right workspace role |
| Time to change a threshold | Days to weeks, depending on the release cycle | Minutes to change, then test and publish |
| Readable by the business | No, it is code | Yes, a step-by-step visual workflow |
| Testing a change | Unit tests written and run by developers | Run with your own example values and read the trace |
| Explaining a past decision | Depends on what was logged at the time | Every call recorded with inputs, outputs and trace |
| Versions | Code history in source control, read by developers | Draft, Active and Inactive versions, earlier versions kept |
| Reuse across systems | Often copied into each application | One published decision called by any system over REST |
| Speed at run time | Very fast, it runs in process | Compiled and cached, answers in milliseconds |
| Best suited to | Logic that rarely changes and belongs to the application | Business policy that changes and needs to be explained |
FAQ
Questions people ask
Is a rules engine better than hard-coding business rules?
Not always. Code is fine for logic that rarely changes and belongs to the application itself. A rules engine pays off when the rule is business policy: limits, eligibility, approvals and pricing that change often and that people need to understand and explain.
How do I separate business rules from application code?
Pick one decision that changes often, write it down as inputs, rules and outputs, rebuild it in Condexa, and test it against real cases until the answers match. Then replace the code with a single API call to the published decision. Move the next rule when the first one is live.
Will calling an external decision slow my application down?
Condexa compiles workflows and caches decisions, so answers come back in milliseconds. For most business transactions, such as an order, a purchase order or a credit check, that is not noticeable.
Do developers lose control?
No. Developers decide where the call is made and what happens with the answer. Workspace roles control who can author and who can publish, so changes to live decisions stay with named people.
What happens if a new version gives the wrong answer?
You test a Draft with example values before it becomes Active, and earlier versions are kept. Run history shows exactly which version answered each call and why.
Keep exploring
Related decisions and guides
Problems
Hard-coded business rules
Every threshold change is a dev ticket and a release. Move the rules out of the code and back to the people who own them.
Read moreProblems
Rule changes need developers
Waiting weeks for IT to change one threshold? Let the people who own the policy change it themselves, safely.
Read moreIntegrations
REST API
Your app needs an answer, not another rules module to maintain. Send the facts, get the decision back as JSON.
Read moreFeatures
Versioning
Nervous about changing a live rule? Draft it, test it, publish it, and keep every earlier version to fall back on.
Read moreCompare
Build vs buy a rules engine
Building your own rules engine looks simple. The versioning, testing, tracing and support are where the work is.
Read moreYour next rule change does not need a release
Bring a decision your team makes every week. We will build it with you, live, test it against your own examples and show your systems calling it.
No slides. Your decision, built live. No obligation.