Why hardcoded settings create future problems

You need to add a new warehouse, a new VAT rate, or a new pricing tier — and suddenly a developer has to go digging through code to find where that logic lives. Not because the business logic is complicated, but because someone, years ago, typed a fixed value directly into a script, a calculation, or a layout instead of putting it somewhere it could be changed safely. That single shortcut is now costing you a support ticket, a delay, and possibly a production error.

This is one of the most common — and most underestimated — causes of software that becomes harder to maintain every year it runs. This article explains what hardcoded settings actually are, why they feel harmless when they're written, why they become expensive later, and how to find and fix them before they cause real damage.

What exactly is a "hardcoded setting"?

A hardcoded setting is any value that's baked directly into the logic of your software instead of being stored somewhere it can be looked up, changed, or managed.

Concrete examples we see constantly in FileMaker and ERP systems:

• A script that says If ( Company = "Acme BV" ) then apply 9% discount instead of reading the discount rate from a customer or pricing table.
• A VAT percentage of 21 typed directly into an invoice calculation, instead of pulled from a VAT rates table tied to a date range.
• A warehouse code like "WH-NL-01" written into a shipping script, instead of read from a warehouses table that can grow.
• An API connector with the production URL of an accounting package typed directly into a script step, so switching to a test environment means editing the script itself.
• A layout that only shows fields for "NL" and "BE" customers because those were the only two countries the company shipped to when it was built.

None of these are bugs on day one. They work perfectly — until the business changes.

Why does this feel like the right choice at the time?

Hardcoding is almost always a rational, well-intentioned shortcut under deadline pressure. A developer — in-house or external — is asked to "just get the discount logic working for the Belgium office by Friday." Building a fully configurable rules engine would take three extra days; typing the rule directly into the script takes twenty minutes.

This is not laziness. It's a legitimate trade-off between speed now and flexibility later. The problem isn't that the shortcut was taken — it's that nobody flagged it as a shortcut, documented it, or came back to fix it once the deadline pressure was gone.

Why do hardcoded settings become expensive later?

The cost of a hardcoded value doesn't show up when it's written. It shows up months or years later, in one of these predictable ways:

1. The business grows past the assumption. The system was built for one legal entity, one country, one currency, or one warehouse. Now there are three. Every place that assumed "one" needs to be found and rewritten.
2. A rule changes that everyone assumed was fixed. VAT rates change. Shipping carriers change their API endpoints. A customer that always got a manual 5% discount is acquired and needs different terms. If that rule lives in ten scripts instead of one table, someone has to find and update all ten — and almost always misses one.
3. Nobody who wrote the code still works there. The person who typed "Acme BV" into that script six years ago left the company. The current developer has to reverse-engineer why that condition exists before they dare touch it.
4. Testing becomes risky. If a test environment and a production environment share a hardcoded API URL, connector, or file path, testing a new integration can accidentally push real data into a live system.
5. Small requests take disproportionately long. "Just add a new discount tier" should be a five-minute configuration change. Instead it becomes a half-day search through scripts, layouts, and calculations to find every place the old tiers were assumed.

That last point is the one business owners feel most directly: the software that used to be cheap and fast to adjust starts to feel slow and expensive to touch, even though nothing about the business logic actually got more complex.

How do you tell the difference between a setting and a constant?

Not every fixed value is a problem. The skill is knowing which values are genuinely stable and which only look stable today.

Ask this question for any fixed value in your system: "Could a non-technical person reasonably need to change this without a developer?"

• If yes — it's a setting, and it belongs in a table, a preferences screen, or a configuration record. Examples: VAT rates, discount tiers, warehouse lists, email templates, approval thresholds, API credentials.
• If no — it's a genuine constant, safe to leave in code. Examples: the number of days in a week, a mathematical rounding rule, a fixed internal ID format that will never need business-side editing.

A useful rule of thumb from real projects: if a value refers to money, tax, geography, an external system's address, or an organizational structure (departments, warehouses, legal entities, customer tiers), assume it will change and build it as a setting from the start. Those five categories account for the vast majority of hardcoded-value support tickets we see.

What does a well-structured settings layer actually look like?

In practice, fixing this doesn't mean rebuilding everything as a generic rules engine — that's overkill and creates its own maintenance burden. It means giving each category of variable data a proper home:

• A settings/preferences table for single global values (company name, default currency, fiscal year start).
• Lookup tables with effective dates for anything that changes over time but needs history — VAT rates being the classic example, since you still need last year's rate to reprint an old invoice correctly.
• A dedicated table per business dimension — warehouses, price tiers, discount rules, shipping carriers — rather than cramming everything into one giant "settings" table that nobody can navigate.
• Environment configuration kept outside the logic layer — API endpoints, credentials, and connector URLs stored in a config table or environment variable, never typed into a script step, so switching between test and production doesn't require editing code.

How do you find hardcoded settings that already exist in your system?

If your FileMaker or ERP system has been running for a few years, you almost certainly have some. A practical audit doesn't require rewriting everything at once — it requires finding and prioritizing:

1. Search all scripts and calculations for literal values. In FileMaker, search scripts for quoted text and numbers that look like business rules — percentages, currency codes, country codes, specific customer or product names.
2. Grep for known "changeable" categories first. Search specifically for VAT/tax percentages, currency symbols, and country/language codes — these are the highest-frequency offenders.
3. Flag every If ( CompanyName = ... ) or If ( CustomerID = ... ) style condition. These are almost always a sign that a rule should live in a table row, not a script branch.
4. Check integration scripts for embedded URLs or credentials. These cause the most damage when they leak into version control or get copied between environments.
5. Rank findings by change frequency, not by how easy they are to fix. A rarely-touched hardcoded constant is low priority. A VAT rate or discount rule that finance asks to adjust twice a year is urgent, even if fixing it takes longer.

What's the right way to fix one without breaking production?

Once you've found a hardcoded value worth fixing, resist the urge to "just replace it everywhere at once." A safer sequence:

1. Create the settings table or configuration record first, and populate it with the current hardcoded value — so behavior doesn't change yet.
2. Update one script or calculation to read from the new setting instead of the literal value, and test that specific flow in isolation.
3. Confirm the output is identical to before the change (same invoice total, same shipping label, same discount amount).
4. Repeat for each place the old value was duplicated — and note how many places you actually find. That count is often the clearest evidence of how much hidden risk was there.
5. Only after every reference is migrated, remove the old hardcoded literal so nobody can accidentally revert to it.

This is exactly the kind of incremental, low-risk cleanup described in our broader guide on how to keep business software maintainable as it grows — hardcoded settings are one of the most common specific symptoms of the general maintainability problem covered there.

Checklist: is your system accumulating hardcoded settings?

• Can a manager change a VAT rate, discount tier, or shipping rule without asking a developer to edit a script?
• Do any scripts contain If ( CompanyName = ... ) or similarly named-entity conditions?
• Are API URLs, credentials, or file paths typed directly into scripts rather than stored in a config table?
• Has adding a new warehouse, country, or price tier ever required more than one script to be edited?
• Does your test environment share hardcoded production URLs or credentials with the live system?
• Do historical documents (old invoices, old orders) still calculate correctly after a rate or rule changed?

If you checked more than one or two boxes, it's worth scheduling a targeted audit before the next business change forces the issue.

FAQ

Is hardcoding always bad practice? No. Genuine constants that no business user would ever need to change are fine to hardcode. The mistake is hardcoding business rules — anything involving money, tax, geography, or organizational structure — that will predictably change.

Why does this matter more in FileMaker than in other platforms? It doesn't matter more technically, but FileMaker's low barrier to quick scripting makes it especially easy to type a value directly into a script under time pressure, since there's no compiler or code review forcing a second look. The flexibility that makes FileMaker fast to build in is the same flexibility that lets shortcuts slip through unnoticed.

How much does fixing this typically cost compared to the original shortcut? In our experience, retrofitting a proper settings structure after the fact typically takes three to five times longer than building it correctly the first time, because you first have to find every place the value was duplicated before you can safely centralize it.

Should every new project start with a settings layer, even if it seems unnecessary now? For any value tied to money, tax, geography, or organizational structure, yes — the up-front cost of a small settings table is minutes, while the cost of retrofitting one later is measured in days.

Hardcoded settings are rarely a sign of bad developers — they're usually a sign of reasonable shortcuts that nobody circled back to fix. If your team keeps running into small changes that take longer than they should, or you're not sure how many of these shortcuts are hiding in your current FileMaker or ERP system, Loggix can help map them out — whether that means a focused audit, restructuring part of a custom FileMaker solution, cleaning up an API integration, or simply a consultancy session to prioritize what's worth fixing first.