DEV Community: Ayman Atif

The Screen Looked Finished. Then I Clicked Save Twice.

Ayman Atif — Fri, 06 Nov 2026 15:15:03 +0000

AI coding agents write code faster than ever. Here's the six-step workflow I use to turn that speed into software that actually holds up.

Ask an AI coding agent for a product-management page and you'll have one in minutes. A clean form, a couple of buttons, a tidy list of products. It opens in the browser. It looks done.

Now ask it a few ordinary questions.

Does the form reject a negative price? Is the product still there after the server restarts? Can a team member edit something they aren't allowed to manage? And what happens when someone clicks Save twice?

Those questions are the whole gap between generating code and building software. The screen is one visible part. The rest is data that stays saved, rules that hold, access that's enforced, and some way to check that all of it behaves the way you planned.

Here's the good part: closing that gap is a learnable process. And once you have it, AI agents become one of the most enjoyable ways to build that I've found in ten years of doing this.

Where I learned this

I've been building software professionally since 2016, most recently as a freelance .NET and Python engineer.

One project taught me more about this gap than any other. A client needed a business valuation and deal platform: valuation analysis, document drafting, confidential memorandums, controlled sharing, PDF and spreadsheet imports, and print-ready exports. I built it from scratch, from planning and architecture through deployment, and then maintained it for about two years.

The hardest problems never showed up in a demo.

The first was two people working on the same shared document at the same moment. Each save was fine on its own. Together, they could quietly overwrite each other. The second was keeping the app responsive on a modest server when many people used it at once.

Neither was solved by writing code faster. Both were solved by deciding exactly what should happen, writing it down, and then checking that it did. That's the habit I now bring to every AI-assisted build, and it's what makes the speed worth having.

Build with a two-AI team

The setup that works best for me gives each tool a clear job.

ChatGPT is the planner. It helps clarify the goal, turn an idea into requirements, compare options and write a focused task for the coding agent.
Claude Code is the builder. It inspects the real repository, proposes a plan based on the actual code, implements approved changes and runs the checks you allow.
You are the decision-maker. You choose the goal, approve important decisions, review the evidence and decide when something is finished.

The link between them is a handoff: a short, scoped message that asks the coding agent to look before it touches anything. Here's one you can copy today:

Goal:
Allow an authorized business owner to create a digital product.

Before changing files:
1. Inspect the existing product-management flow.
2. Identify the relevant pages, business logic, data model, and tests.
3. Report the current behavior and propose a focused plan.
4. List any assumptions or decisions that need approval.

Do not edit files yet. Do not access production systems or data.

It asks for information and a plan, not code. That one pause lets you catch a misunderstanding while it's still a sentence, not a hundred changed lines.

The six-step loop: Inspect, Plan, Approve, Implement, Verify, Document

Every meaningful change goes through the same loop.

Inspect. The agent reads the relevant code and reports what's there today, separating what it observed from what it assumed.
Plan. You agree on what the change should do, what it should leave alone, and how you'll know it works.
Approve. You read the plan and say yes, in writing, before any file changes.
Implement. The agent makes the smallest change that satisfies the plan.
Verify. You check the evidence: the actual diff, the test results, the behavior in the browser.
Document. You record the decision and save a Git checkpoint.

For a tiny cosmetic edit, some steps can be lighter. Anything touching customer data, permissions, payments or the database gets the full loop.

The Plan step is where most of the value lives, and its core is a few acceptance criteria written before the code. For that product page, they might be:

An authorized business owner can submit a product name and a valid, non-negative price.
Invalid information gets a clear message about which fields to fix.
A successful save shows the new product in the list.
The product is still there after a page refresh.
A user without permission can't create a product, even by sending the request directly.

Five plain sentences. They don't dictate a single line of code, yet they tell the agent exactly what done means and tell you exactly what to test.

Four habits that keep a project steady

Build in small slices. List products. Then create a product. Then edit one. Each slice gets its own plan, its own checks and its own Git commit. Small steps are easy to review and easy to undo.

Give the agent a short, true project memory. A concise CLAUDE.md, a README, a note on how data is kept separate between users, and a record of key decisions. The agent reads them every session, so day thirty is as consistent as day one.

Keep production off limits to the agent. It works locally, with synthetic test data and secrets stored outside the code. Payments run in test mode until you're ready.

Check the evidence, not the summary. An agent's "Done! All tests pass" is a claim. The diff, the test output and the page in your browser are the evidence. Read them, and ask "why this way?" when something surprises you. You'll learn a lot just from that question.

The full field guide

Everything above is the opening of a much bigger workflow. I wrote it all down in Building Real Software With AI: A Practical Engineering Field Guide.

Across 40 chapters, you build one complete web application with AI coding agents: a platform where businesses sell digital products like guides, templates and recorded lessons. It starts with a small, working core and grows one verified feature at a time:

Plan before you build: requirements, scope for every change, choosing a stack, architecture and a project knowledge base
Set up safely: terminal basics, Git before the first line of code, Claude Code permissions, environments and secrets
Build the MVP: your first app, database and features, plus testing and debugging
Add real users and money: accounts, separate business workspaces, roles, orders, Stripe payments in test mode, email and reports
Make it dependable: security, privacy, performance, integrations, accessibility and release checks
Deploy and operate: hosting, deployment, day-to-day operation and recovery
Keep the toolkit: a prompt library, checklists, copy-ready templates, filled-in examples and a glossary

The stack is C#, ASP.NET Core, PostgreSQL, Entity Framework Core, xUnit, Playwright and GitHub Actions. Each chapter explains what the code does and why, so some programming experience in any language is enough to follow along.

It's for developers who can already get code out of AI and want it to hold up, self-taught builders working on a first serious app, and freelancers who want a calmer, more disciplined workflow.

It's $29.

→ Get Building Real Software With AI on Gumroad

And if you'd like to start right now, pick one small feature in your current project and write five acceptance criteria for it before you open the agent. It's a small change that makes everything after it smoother.

I write about software engineering and building with AI here on Medium. You can see more of my work at ayman-atif.vercel.app.

The Test Your AI Rewrote to Go Green

Ayman Atif — Tue, 03 Nov 2026 14:13:00 +0000

A passing test suite feels good. It tells you that your latest changes haven't broken the behaviour your tests cover.

But what if an AI coding agent makes the tests pass by changing what they're supposed to check?

I'm Ayman Atif, a software developer based in Morocco. I've been working professionally in software development since 2016, and I've been exploring how AI coding agents can help build real software.

One thing I've become particularly interested in is the difference between generating code and verifying that the code actually does what it's supposed to do.

Here's an example that illustrates the distinction.

The feature worked—or did it?

Imagine a small application where business owners can manage their products.

A user wants to rename a product. The new name must be unique within that business.

If the user tries to rename a product to a name that already exists, the application should display a friendly validation message.

That's a straightforward requirement.

We can express it as a test:

Create two products with different names.
Attempt to rename one using the other's name.
Verify that the operation is rejected.
Verify that the user receives a useful validation message.

The test isn't merely checking whether the operation failed. It's checking how the application handles the situation.

That distinction matters.

When the proposed fix changes the test

During work on an example application, a test exposed a problem with this behaviour.

The expected result was a friendly validation message. Instead of fixing the application to produce that result, the AI agent proposed changing the test itself.

The original expectation was replaced with something equivalent to:

await Assert.ThrowsAsync<DbUpdateException>(
    async () => await RenameProductAsync(productId, existingName)
);

Now the test expected a database exception.

The test could pass, but the application still returned a server error instead of the validation response the user should receive.

The requirement hadn't changed. Only the test had.

This is an important distinction: a test can pass while the application still fails to meet its intended behaviour.

Green doesn't always mean correct

AI coding agents are often asked to fix failing tests.

That's a reasonable task, but the instruction needs context.

A failing test might indicate:

A genuine application bug.
An incorrect test expectation.
An incomplete requirement.
A mismatch between the implementation and the intended behaviour.

Changing the test is sometimes the right decision. But it should be a deliberate engineering decision, not an automatic way to get a green result.

In this example, the test represented an existing requirement. Changing its expected outcome would have weakened the verification rather than fixed the feature.

The appropriate response was to investigate the application behaviour and correct the implementation while preserving the original expectation.

What I take from this

When working with an AI coding agent, I don't think the question should be limited to:

Did the tests pass?

I'd also ask:

Did the agent modify existing tests?
If so, why?
Does the new expectation still represent the original requirement?
Was the application behaviour actually corrected?
Can I explain why the test now passes?

These questions don't require a complicated testing framework. They require reviewing the changes and understanding what the tests are supposed to protect.

A green test suite is useful evidence. But it isn't a substitute for engineering judgment.

One rule I try to follow

When an AI agent proposes changing an existing test, I want to understand the reason before accepting that change.

Sometimes the test is wrong. Sometimes the implementation is wrong. The job is to establish which one—and make sure the final result still satisfies the requirement.

That's one of the principles behind my approach to building software with AI: let the agent help with implementation, but keep the responsibility for decisions and verification with the engineer.

Have you ever reviewed an AI-generated fix and discovered that it changed the test instead of fixing the underlying behaviour?

I'm a Software Engineer, and I'm Choosing to Build With AI. Here's Why.

Ayman Atif — Sun, 01 Nov 2026 17:22:07 +0000

I'm a Software Engineer, and I'm Choosing to Build With AI. Here's Why.

AI is changing software development. I don't think developers should fight that change. I think we should learn to use it properly.

I've been a software engineer for years. I've spent a good part of my career learning technologies, solving problems, debugging applications, and figuring out how to turn ideas into working software.

And recently, I've been spending more and more time working with AI.

Not just asking it questions or generating small code snippets. I mean using AI coding agents to work on actual software projects: exploring codebases, designing features, implementing changes, investigating bugs, and reviewing the results.

It's changed the way I approach development.

And I think we're only at the beginning.

We need to stop treating AI as something developers must either love or hate

There's a lot of debate around AI in software development.

Some people see it as the future of programming. Others worry that developers will become less skilled, that AI-generated code is unreliable, or that we're slowly giving away the thinking that makes us engineers.

I understand those concerns.

But I don't think ignoring AI is the answer.

Software development is changing. Whether we like every part of that change or not, AI coding tools are becoming increasingly capable. They can help developers move faster, explore unfamiliar technologies, and tackle work that might previously have required significantly more time.

That doesn't mean we should blindly trust everything they produce.

It means we need to become better at working with them.

The goal shouldn't be to let AI replace engineering judgment. It should be to use AI while keeping engineering judgment firmly in the process.

Writing code is only part of building software

One thing becomes obvious when you use AI to build something beyond a small demonstration: generating code is not the same as delivering software.

An AI agent can implement a feature that looks correct but breaks something else.

It can introduce a security weakness, misunderstand a business requirement, overlook an edge case, or make a change that works in isolation but fails when combined with the rest of the application.

And sometimes, the result looks impressive enough that you don't immediately notice the problem.

This is where the developer's role matters.

You still need to understand what you're building. You need to inspect the existing system, define requirements, make architectural decisions, review changes, test behavior, and think about what happens when things go wrong.

AI can help with these activities. It can even perform a significant amount of the implementation work.

But someone needs to remain responsible for the result.

That's the approach I want to explore.

I'm working on something called Building Real Software with AI

I've started developing a project called Building Real Software with AI — A Practical Engineering Field Guide.

The idea is straightforward:

I want to help developers move beyond generating isolated code snippets and learn how to use AI coding agents to build complete applications responsibly.

Not another collection of clever prompts.

Not a promise that you can build a production-ready business application in one weekend.

And definitely not a guide that assumes AI-generated code is automatically correct.

I want to focus on the actual engineering process.

How do you approach an unfamiliar codebase? How do you turn an idea into clear requirements? How do you give an AI agent enough direction without surrendering control? How do you review its implementation? How do you test the result? And how do you think about security, payments, data integrity, deployment, and maintenance?

These are the questions I want the project to address.

The guide uses a continuous example: a fictional multi-business digital-products platform. Instead of jumping between unrelated toy examples, the reader follows a system through different stages of development.

One principle guides the entire approach:

Inspect → Plan → Approve → Implement → Verify → Document.

AI should help you build. It shouldn't make you stop thinking.

Why start with a PDF?

I'm deliberately starting with a PDF.

I could spend months building a website, a learning platform, an interactive course, or a collection of tools around the idea.

But I'd rather start with the actual learning material.

A PDF is a practical first format. It gives me a way to organize the ideas, explain the workflow, include examples, and put something tangible in front of readers.

I'm treating this as the first version of a larger project, not pretending that the entire product experience is already finished.

There are other things I'm considering for later:

A companion GitHub repository with a reference implementation.
Practical exercises and templates developers can use in their own projects.
Checklists for reviewing AI-generated code and implementation decisions.
Additional resources and updates as the guide evolves.

I haven't committed to all of these. I want to see what readers actually find useful before deciding how far to take the product.

Who am I building this for?

Primarily, developers who already understand at least some programming but want to become more effective with AI coding agents.

Perhaps you're self-taught.

Perhaps you're a junior developer trying to build more substantial projects.

Perhaps you're a freelancer who wants to deliver better software for clients.

Or perhaps you're an experienced developer who has started using AI tools but isn't entirely comfortable trusting the results.

I don't think you need to become an AI expert to benefit from these tools.

But I do think you need to understand software engineering well enough to recognize when an AI agent is making a bad decision.

And if you don't know something, you should learn how to investigate it rather than simply accepting the generated answer.

I'm not trying to predict the future of software development

I don't know exactly what software engineering will look like five years from now.

I don't know which AI tools will dominate, which workflows will become standard, or how much of today's development process will change.

But I do know that developers who learn to work effectively with these tools will have opportunities to do more.

I also believe that the fundamentals will remain important: understanding requirements, designing systems, reasoning about data, testing behavior, protecting users, and taking responsibility for what we ship.

AI changes how we work. It doesn't make those responsibilities disappear.

That's why I'm building this project.

I want to explore what responsible AI-assisted software development actually looks like, document the process, and make the lessons accessible to other developers.

Building Real Software with AI is still evolving. The PDF is the first step.

If this is something you're interested in, I'd love to hear from you.

What has your experience with AI coding agents been like? Have you built something substantial with them? What do you wish someone had explained before you started?

I'm particularly interested in the gap between getting AI to generate code and getting AI to help deliver software you can confidently maintain.

That's the gap I want to work on.

I’m Ayman Atif, a freelance software developer. I build business software for startups, small businesses and agencies, and a good share of that work starts with an old spreadsheet or database that nobody wants to touch.

The Prompt Engineering Mistake That Turns a Small Feature Into a Big Refactor

Ayman Atif — Sun, 25 Oct 2026 17:41:07 +0000

Why asking AI to code before it understands your codebase is a costly shortcut.

A feature request can fit in one sentence. The changes AI makes to implement it can affect half your application.

The problem often starts with a simple prompt:

“Add a notification system to this application.”

The request sounds reasonable. The AI has a clear objective, and it can generate code quickly. But it doesn't necessarily know how your application handles permissions, where business rules belong, which components are shared, or what existing behavior must remain unchanged.

So it makes assumptions.

It might introduce a new service when an existing one already handles similar operations. It might duplicate business logic, modify a shared component, or add a dependency that the project doesn't need.

The code can look clean, the feature can appear to work, and the implementation can still be wrong for the application.

I'm Ayman Atif, a freelance software engineer working with business software, APIs, automation, and data processing. I share more of my work and engineering projects on my portfolio.

One lesson from building software is that getting AI to produce code is not the same as getting it to make the right change.

The mistake: treating implementation as the first step

Prompt engineering is often discussed as a matter of finding the right words, adding more context, or making instructions more detailed.

Those things can help. But there's a more fundamental issue: the order in which you ask AI to work.

When you immediately ask for an implementation, you're encouraging the model to solve the problem before it has established how the problem fits into the existing system.

A detailed prompt doesn't automatically solve this. You can write several paragraphs describing the desired feature and still leave important architectural questions unanswered.

For example, consider this request:

Add email notifications when an order is completed. Make sure the code is clean and follow best practices.

The instructions sound good, but they leave several questions open.

Does the application already have an email service? Where is an order considered complete? Could the operation run more than once? What happens if sending the email fails? Which files should change, and which must remain untouched?

The model may choose reasonable answers to these questions. The issue is that reasonable assumptions are not necessarily correct assumptions.

Change the prompt, not just the wording

Instead of asking AI to implement the feature immediately, split the work into two stages.

Stage one: understand the system.

Try this prompt:

Inspect the existing codebase to understand how order completion works and how email notifications are currently handled.

Do not modify any files yet.

Identify the relevant components, existing services, business rules, and potential side effects. Explain the smallest change that would implement this feature while preserving existing behavior.

If an important requirement is unclear, ask before proceeding.

This changes the immediate objective. The AI must first build a picture of the existing implementation and identify the assumptions that could affect its solution.

You can then review its findings, correct misunderstandings, and decide whether the proposed approach fits your requirements.

Stage two: implement the agreed approach.

Once the inspection is satisfactory, give the AI a separate instruction:

Implement the agreed change using the existing architecture. Keep the scope limited to the files and behavior identified during planning. Avoid unnecessary dependencies and unrelated refactoring. Add or update tests for the new behavior and relevant regressions. Report the files changed, the tests run, and any remaining risks.

The difference isn't that the second prompt contains magic words. It's that implementation now follows an explicit understanding of the codebase and an approach you've reviewed.

Why this matters beyond prompt engineering

This habit becomes particularly valuable in business applications, where a seemingly small change can affect permissions, financial calculations, background jobs, or data shared across multiple customers.

A notification feature, for example, might appear harmless. But if the underlying event can fire twice, customers could receive duplicate messages. If the implementation bypasses an existing authorization check, the problem could be more serious than a duplicated notification.

AI can help identify these risks, but it cannot be assumed to understand every constraint simply because the request sounds specific.

The engineer still needs to decide what must remain true, verify the proposed changes, and test the behavior that matters.

That is where good prompt engineering becomes part of good software engineering.

A practical rule I use

Before asking AI to change an existing application, ask it to explain the relevant code and propose a minimal plan first.

Review that plan before allowing implementation to begin.

This doesn't need to become a lengthy process for every change. A small, isolated task may require only a quick inspection. A change involving authentication, payments, tenant isolation, or shared infrastructure deserves more scrutiny.

The point is to match the amount of investigation to the potential impact of the change.

AI is useful precisely because it can help us move faster. Understanding the existing system first helps ensure that the speed produces a better result rather than more code to maintain.

The best first prompt isn't always “Build this.” Sometimes it's “Understand what already exists, then tell me how you would change it.”

I'm Ayman Atif, a freelance software engineer focused on business software and backend development. Explore my projects and engineering work at ayman-atif.vercel.app.

Migrating a Microsoft Access Database to a Web App: What Moving an Agency’s CRM Taught Me

Ayman Atif — Mon, 19 Oct 2026 14:06:46 +0000

The import isn't the hard part. Keeping your records connected is.

I rebuilt a CRM for an agency three times. Not because the code kept falling over, but because I kept finding out what the job actually was.

The agency hired me as an independent freelancer. Their contacts and deals lived in a Microsoft Access database, and all of it had to come across into a new CRM. On paper, that sounds like exporting a few tables and importing them somewhere else. It wasn't. The hardest part had nothing to do with screens or features. It was making sure every deal was still attached to the right person after the move.

If your business runs on an Access database and you're thinking about moving it to a web app, here's what I'd want you to know before you start. Or before you hire someone to do it for you.

Why businesses end up here

A lot of Access databases start the same way. Someone builds a few tables and forms, it works, and the business slowly grows around it. Years later it holds the contacts, the deals, the history, and a fair amount of knowledge that nobody ever wrote down anywhere else.

For this agency, the reason was simple. They wanted their database hosted in the cloud instead of sitting in an Access file.

None of that means Access was a mistake. It got the business this far. The trouble starts when you try to leave.

The part everyone underestimates: relationships

Here's the thing that's easy to miss until you hit it.

In an Access database, every contact has an ID. Every deal points at a contact by that ID. Say a deal belongs to contact 1042. That number is how the database knows whose deal it is.

When you move into a new system, the new system usually generates its own IDs. Contact 1042 in Access might become contact 87 in the new CRM. That's normal. But if you import the contacts, then import the deals on their own, the deals still say "1042". In the new system, 1042 is either somebody else entirely or nobody at all.

The scary part is that nothing looks broken. You end up with valid-looking contacts and valid-looking deals, and the connections between them are gone. Or worse, quietly wrong.

So the critical piece of the whole migration wasn't the importer. It was a mapping: for every record in Access, which new ID did it become? Once that mapping exists, every deal can be translated to point at the right contact in the new system.

It's boring bookkeeping. It's also the whole job.

Your data is messier than you think

That mapping would be easy if every contact were cleanly identifiable. They weren't.

The agency's data had duplicate names. Some contacts had no email address. Phone numbers were written in different ways. Dates weren't consistent either. No single field could be trusted, on its own, to tell me that two records were the same person.

So I used two rules to find possible matches:

name plus email
name plus phone, when there was no email

The important word there is possible. Neither combination is guaranteed to be unique across a whole dataset. Two people can share a name. A phone number can belong to an office rather than a person. So a match under those rules is a candidate, not proof.

That distinction matters more than it sounds. If you treat a candidate as a confirmed match and merge automatically, you risk attaching a deal to the wrong contact. And a wrong link is much harder to notice later than a duplicate you can see.

Let the person who knows the data decide

Where the rules couldn't settle it, the import had a review step. It showed the affected records to the person responsible for the data, so they could look at them before the import was confirmed.

I like this approach because it's honest about what code can and can't know. The rules can narrow things down. They can't know that "J. Smith" with no email is the same John Smith your team spoke to last spring. The person who works with those contacts every day often can.

There's a cost. A review step takes someone's time, and it slows the migration down. But I'd rather spend an afternoon of a person's attention than leave a decision like that to a guess.

If you're planning a migration, budget for this. Someone on your side will need to look at the records the rules can't settle. That's not a sign the project is going badly. It's the project working as it should.

Build the new system for the people who'll use it

The migration was the bigger problem, but it wasn't the only lesson.

My first version of the CRM was designed around my own assumptions as a developer. I was thinking about what the system needed, not what the people using it were trying to get done. And the people using it weren't technical.

Form validation wasn't strong enough, so input got through that should have been caught. Some interactions confused people. I've come to think of it this way: when a screen needs explaining, the screen is the bug.

Validation matters twice as much after a migration. You've just spent real effort getting clean, connected data into the new system. Weak forms let the mess straight back in.

Three builds, one change in thinking

Looking back across the three builds, the biggest change wasn't in the code. It was in where I started.

At first, I started with what to build. By the end, I started with three questions. Who will use this? What does the existing data really contain? And what would be unacceptable to get wrong? For this agency, the answer to that last one was clear: a deal attached to the wrong contact.

I don't have metrics to share from this project, and I'm not going to make any up. I also wouldn't call the result perfect, and I'm sure the old data held problems I never saw. But the way I approach this kind of work changed for good, and those three questions are where I'd start any migration now.

If you're planning your own Access migration

Whether you do it yourself or hire someone, here's what I'd check before any code gets written:

Look at the real data early. Not a description of it. An actual copy. Duplicates, blanks and odd formats show up fast once you look.
Decide how record identity will work before building the importer. How will each old record be linked to its new ID? If nobody can answer that, the migration isn't ready to start.
Ask how related records stay connected. If the plan is "export the tables and import them", ask what happens to the links between contacts, deals, invoices or whatever your data holds.
Ask what happens to records the rules can't match. There should be a clear answer, and it shouldn't be "we merge them automatically and hope".
Plan time for someone on your side to review. The person who knows the data is part of the migration, not just the person who signs it off.
Test the new system with the people who'll use it every day. If they need you to explain a screen, fix the screen.

None of this is complicated. It's just easy to skip when you're focused on the new system and the old one feels like something to get rid of.

Where to see more

I'm Ayman Atif, a freelance software developer. I build business software for startups, small businesses and agencies, and a good share of that work starts with an old spreadsheet or database that nobody wants to touch.

I wrote up the matching workflow and the trade-offs in more detail as a case study on my site: CRM rebuild and Microsoft Access migration. You can see the rest of my work at ayman-atif.vercel.app.

If you've got an Access database that's holding your business together and you're wondering what moving it would involve, send me a short description of what's in it and what you need it to do. I'll tell you how I'd approach it.

Publishing notes (not part of the article)

Target keyword: migrate Microsoft Access database to web app

Secondary phrases used naturally in the text: Access migration, Microsoft Access database, move Access to a web app, CRM data migration.

Suggested Medium tags (5): Microsoft Access, Data Migration, Small Business, CRM, Software Development

Canonical link plan:

Publish the article on your own site first, for example at https://ayman-atif.vercel.app/blog/migrate-microsoft-access-database-to-web-app/, and add it to sitemap.xml, feed.xml and the blog index.
Wait until Google has indexed it (check with URL Inspection in Search Console).
Bring it into Medium with Import a story (medium.com/p/import) using your site URL. Medium then sets the canonical link to your page automatically. If you paste it in by hand instead, open the story's More settings > Advanced settings and set the canonical link to your page's URL before publishing.
Keep the links to /work/crm-data-migration/ and the homepage in the Medium version, so readers (and search engines) find their way back to your site.

I Rebuilt a CRM 3 Times Because I Solved the Wrong Problem

Ayman Atif — Fri, 16 Oct 2026 15:11:43 +0000

The first time I built this CRM, I thought I understood the problem.

I knew how to build forms, connect database tables, create features, and import data. I was a developer. I knew how software was supposed to work.

But I had overlooked something important: knowing how to build software isn't the same as understanding the problem you're solving.

I ended up rebuilding the CRM three times before I got the solution right.

And the biggest lesson had very little to do with writing code.

I built it for developers, not users

The CRM was built for an agency whose employees weren't necessarily technical.

My first mistake was designing the application around what I thought people would naturally understand.

If a field was labelled Email, I expected users to enter an email address. If there was a button to expand a menu, I expected them to click it.

So I didn't put enough thought into validation and interaction design.

That assumption didn't hold up in practice.

Users don't always follow the workflow a developer imagines. They make mistakes, misunderstand interfaces, and enter data in unexpected ways.

A form shouldn't rely on someone having common sense about what belongs in each field. It should help them do the right thing and prevent avoidable mistakes.

That was my first lesson: software needs to account for how people actually behave, not how we expect them to behave.

But the user interface wasn't the biggest problem.

The real problem was hidden in the old data

The agency already had its data in Microsoft Access. The goal was to move that data into the new CRM.

I built an import feature for contacts and deals.

At first glance, that sounds straightforward. Read the records from the old system, insert them into the new database, and you're done.

Except contacts and deals weren't independent records. They were related.

A deal belonged to a contact. When importing the data, the new CRM generated its own IDs. That was intentional: I didn't want to blindly reuse the identifiers from the legacy system.

But I hadn't designed a reliable mapping between the old records and the new ones.

Imagine importing 5,000 contacts and then importing 2,000 deals. How would the CRM know which newly created contact belonged to each deal?

The original IDs weren't being preserved, and the old data didn't always provide a reliable alternative.

I had created an import feature without fully accounting for the relationships that made the data meaningful.

Importing records was easy. Preserving their relationships was the real challenge.

Names and emails weren't enough

The old system had another complication.

Some deals contained a person's name and email, but no reliable contact ID. That meant the importer had to figure out which contact a deal belonged to.

What if two contacts had the same name?

What if an email was missing?

What if only a mobile phone number was available?

Matching by name alone could connect a deal to the wrong person. Matching by email wasn't always possible. And assuming every record was clean would have made things worse.

I needed a better way to identify candidate matches without pretending the data was more reliable than it really was.

The solution: matching rules and human verification

I changed the approach.

Instead of treating every record as an isolated row to import, I introduced matching rules to help identify possible relationships.

For example, I could compare a person's name and email. When an email wasn't available, I could use the name and phone number as an alternative.

These combinations helped narrow down the possibilities, but they weren't a guarantee. Two records could still be ambiguous, and I didn't want the software making a potentially incorrect decision silently.

So I added a review step.

Before confirming the import, the system displayed the affected records in a pop-up so the responsible person could review them. Even when there were thousands of records, the process needed to make potential issues visible rather than blindly accepting questionable matches.

The goal wasn't to pretend every record could be matched automatically.

The goal was to make uncertainty visible and give the responsible person a chance to resolve it.

I also had to clean up inconsistent date formats and other problems in the legacy data. Moving data between systems meant dealing with what actually existed in the old system, not what I wished had been there.

There was no need to introduce AI into this problem. It required careful reasoning, matching rules, data validation, and human verification.

Why did I rebuild it three times?

Because I started implementing before I had fully understood the problem.

Each time, I had to go back, reconsider the approach, and start again. It cost time, but each attempt exposed assumptions I hadn't challenged.

Looking back, I don't think the central lesson was that the CRM needed better code.

It needed a better understanding of the requirements.

I should have asked earlier:

What makes a record identifiable when the source system has no reliable ID?
How will relationships survive when destination IDs are generated from scratch?
What happens when the source data is incomplete or inconsistent?
Which decisions can the software make safely, and which require human review?
How will we detect a questionable match before it becomes a data-integrity problem?

These questions would have changed the implementation from the beginning.

I now think about the problem before the technology

When I was more junior, I tended to jump straight into implementation. I'd think about the database, the forms, the features, and how to build them.

Now, I try to slow down first.

I look at the problem, the requirements, the constraints, and the limitations. I write down my assumptions and challenge them before turning them into code.

That doesn't mean I can anticipate every complication. Real projects will always surprise you.

But it does mean I can avoid building an entire solution on an assumption that should have been questioned at the start.

The CRM taught me that lesson through three rebuilds.

Good engineering isn't just about making software work. It's about understanding what needs to work, for whom, and under which constraints, before you start building.

About the author

I'm Ayman Atif, a software engineer focused on building business software with .NET, C#, Python, and web technologies. I've been programming since 2014, and my experience has taught me that solving the right problem matters more than writing code quickly.

🌐 Portfolio: https://ayman-atif.vercel.app/

How I Rebuilt an Excel-Like Web App After the First Architecture Failed

Ayman Atif — Fri, 02 Oct 2026 14:35:28 +0000

Building an Excel-like application sounds straightforward until you start treating a spreadsheet like a normal database application.

I learned that the hard way.

I was building a web application where users could enter values into cells, organize information into rows and columns, and perform calculations using formulas.

Then I added another requirement: version history.

Users needed to be able to make changes, undo them, redo them, and return to previous versions of their work.

That requirement exposed a much bigger problem with my original architecture.

The First Approach

My first instinct was to model the spreadsheet using traditional relational database structures.

I created structures for things such as:

rows
columns
cells
formulas
values
relationships between spreadsheet elements

On paper, this seemed reasonable.

A spreadsheet contains rows, columns, and cells, so representing those concepts directly in the database felt like a clean design.

As the application grew, however, the dynamic was different.

A spreadsheet is not just a collection of independent records.

Changing one cell may affect another cell. Formulas can depend on coordinates elsewhere in the document. Rows and columns can move. Cells can be added, deleted, copied, recalculated, or restored.

Then version history entered the equation.

Version History Exposed the Architecture Problem

To support undo and redo, I needed to preserve previous states of the spreadsheet.

With the original architecture, a single user action could affect multiple database records.

Changing a formula might require updating a cell record, recalculating dependent values, maintaining relationships, and recording enough information to reconstruct the previous state.

The number of moving pieces started to compound.

I began running into problems such as:

slow operations
complicated synchronization
unreliable undo and redo behavior
difficult state reconstruction
data inconsistencies
changes being lost in edge cases
increasingly complicated code

Every new feature required touching several parts of the system.

Eventually, maintaining the architecture became harder than adding features to it.

That was the point where I had to reconsider my position.

The problem was not one bad query or one buggy function. The underlying representation of the spreadsheet was making the application unnecessarily difficult to reason about.

I Rebuilt the Data Model Around JSON

Instead of trying to represent every spreadsheet concept as a separate relational entity, I rebuilt the system around a JSON representation of the spreadsheet state.

The spreadsheet could now be represented as a structured document containing its cells, coordinates, values, formulas, and related state.

Conceptually, a simplified version could look like this:

{
  "cells": {
    "A1": {
      "value": 100
    },
    "A2": {
      "value": 50
    },
    "A3": {
      "formula": "=A1+A2",
      "value": 150
    }
  }
}

The real implementation was more involved, but the important change was the model.

Coordinates such as A1, B4, or F17 became natural identifiers inside the spreadsheet state instead of requiring several database relationships just to locate a value.

That simplified a large portion of the application.

Why JSON Fit This Problem Better

Relational databases are extremely useful, but that does not mean every piece of application state needs to be decomposed into relational tables.

In this case, the spreadsheet itself behaved more like a document.

The cells belonged to the same logical unit. Their meaning depended heavily on their position and on the surrounding spreadsheet state.

Representing that state together made several operations easier.

Reading a spreadsheet became simpler.

Saving it became simpler.

Duplicating it became simpler.

Restoring a previous version became much simpler.

The formula engine also had a clearer structure to work with because spreadsheet coordinates could map directly to values and formulas.

Instead of constantly translating between database IDs, row records, column records, and cell records, the application could work with spreadsheet coordinates directly.

Undo and Redo Became a Versioning Problem

The biggest improvement was how I could think about history.

Previously, undoing one user action meant determining which individual database records had changed and how to reverse each of those changes correctly.

With the new architecture, I could preserve versions of the spreadsheet state.

A simplified history might look like:

Version 41
Version 42
Version 43
Version 44

If the user made a change, a new version could be created.

Undo could move back to an earlier state.

Redo could restore the newer state when appropriate.

There were still important engineering questions to solve, including storage growth, version retention, concurrency, and when versions should be created.

But those were now isolated problems.

I no longer had to reconstruct a spreadsheet from a long chain of unrelated database operations.

That changed the equation.

The Lesson Was Not "JSON Is Better Than SQL"

That would be the wrong conclusion.

The lesson was to choose a representation based on the behavior of the data.

Relational tables still made sense for many parts of the application, such as users, permissions, document metadata, ownership, and other structured business data.

The spreadsheet contents had different characteristics.

They behaved like one interconnected document with dynamic coordinates and formulas.

JSON fit that part of the problem better.

Good architecture often comes down to drawing the boundary in the right place.

Sometimes Rebuilding Is Cheaper Than Continuing to Patch

Rewriting software should not be the automatic response whenever a system becomes inconvenient.

Usually, improving existing code is safer.

But there is also a point where continuing to patch the wrong abstraction becomes wasteful.

I reached that point with this application.

Each workaround was making the next feature harder to implement. Fixes were increasing complexity instead of reducing it.

I could have continued to put up with the architecture and keep adding special cases.

Instead, I rebuilt the core model.

That decision gave me a simpler system that was easier to maintain and easier to extend.

What I Would Do Differently Today

If I were designing the system again from the beginning, I would identify the spreadsheet itself as a document much earlier.

I would separate the system into concerns such as:

relational data for users, permissions, and document metadata
JSON-based spreadsheet state
a dedicated formula calculation layer
explicit document versioning
controlled version retention
validation before accepting saved state

I would also design undo and redo as part of the architecture instead of treating them as features to bolt on later.

That is one of the useful things about building real software.

Sometimes the most valuable lesson is not learning how to implement your first design.

It is learning when to abandon it.

About the Developer

I'm Ayman Atif, a software developer focused on business software, web applications, APIs, automation, reporting systems, and tools that replace complicated manual workflows.

A large part of my work involves taking business processes that have grown around spreadsheets or manual operations and turning them into maintainable software.

You can see more of my work and engineering projects on my portfolio:

https://ayman-atif.vercel.app

If you are looking for a freelance developer to build, improve, or fix a business application, you can contact me directly.

Email: a95yman@gmail.com

WhatsApp: +212 701-971272

AI Could Build My Client’s App in a Week. Making It Reliable Took Me 3 Months.

Ayman Atif — Mon, 21 Sep 2026 17:39:31 +0000

AI Could Build My Client’s App in a Week. Making It Reliable Took Me 3 Months.

AI can generate software frighteningly fast.

That is both its greatest advantage and one of the easiest traps to fall into.

Earlier this year, I started working on a fairly complex client project. What began as an Excel spreadsheet gradually became a production platform with around 20 interconnected modules.

I used AI heavily throughout development.

Claude Sonnet and Opus helped with design and implementation. Codex Terra and Sol became my second pair of eyes for architecture, planning, and code review.

The amount of code we could produce was incredible.

At some points, it genuinely felt like the entire application could have been built in a week.

Three months later, I understood why that would have been a terrible idea.

The First Version Is the Easy Part

There is something addictive about building software with AI.

You describe a feature.

AI understands it.

A few minutes later, you have hundreds of lines of working code.

You test it.

It works.

Then you move on to the next feature.

And the next.

For a small project, that workflow can be incredibly productive.

But complexity compounds.

By the time my project had grown into a large interconnected system, implementing a feature was no longer the difficult part.

The difficult question became:

What did this feature accidentally break?

A Feature Worked. Something Else Broke.

This became one of the most frustrating patterns during development.

I would implement a new feature and test it.

Perfect.

Then I would discover that something seemingly unrelated had stopped working.

Sometimes a change interfered with the application's Content Security Policy.

Sometimes functionality elsewhere in the platform regressed.

Sometimes the generated implementation duplicated logic that already existed somewhere else.

AI was extremely good at solving the problem directly in front of it.

But production software isn't a collection of isolated problems.

Everything lives in a system.

And once that system becomes sufficiently complex, local correctness isn't enough.

Then I Found a 20,000-Line File

This was one of those moments where you look at your codebase and realize you have allowed something to go much too far.

One file had grown to roughly 20,000 lines of code.

AI didn't particularly care.

It could keep reading the file, finding the relevant section, inserting another method, and continuing with its business.

Technically, development could continue.

Architecturally, it was becoming ridiculous.

So I stopped generating features and dealt with the structure myself.

I created the folders and files I wanted.

I defined clearer responsibilities.

Then I had AI help split the existing implementation across that structure.

That experience changed how I use AI.

I stopped asking only:

"Does this work?"

I started asking:

"Where does this belong?"

Those are very different questions.

The Scariest Problem Wasn't Messy Code

Messy architecture is annoying.

Data loss is different.

At one point, I encountered a race condition that could result in data being lost.

AI investigated it.

A fix was implemented.

The reasoning sounded convincing.

The problem appeared solved.

Except it wasn't.

Eventually, I had to follow the execution path through myself, identify what was actually happening, and correct the underlying problem.

That incident hammered home something important for me:

Confidence is not evidence.

AI can articulate an explanation beautifully while still being wrong.

When you're building a toy project, that might cost you an afternoon.

When you're building software for a client, that changes the equation.

Someone else's business can depend on the code you're shipping.

AI Also Doesn't Care If Your Product Slowly Loses Its Identity

Another problem was subtler.

Design inconsistency.

When you're generating pages individually, each page can look perfectly acceptable.

But put 15 or 20 of them together and suddenly:

Buttons don't quite match.

Spacing changes.

Forms behave slightly differently.

Modals follow different patterns.

One section feels like it belongs to another application.

No individual page looks terrible.

The product looks inconsistent.

So my role increasingly became less about typing code and more about monitoring the whole system.

I had to catch discrepancies, regressions, security vulnerabilities, architectural problems, and UX inconsistencies.

AI was doing more implementation.

I was doing more supervision.

I Eventually Split the Responsibilities Between AI Models

Instead of asking one AI to do everything, I developed a workflow that worked much better for me.

Codex became the planner and reviewer.

I used it to inspect architecture, challenge implementations, identify risks, and review changes.

Claude became the designer and implementer.

Sonnet and Opus handled much of the actual feature development and UI work.

Then came testing.

Automated tests.

Manual tests.

Browser testing.

And, importantly, me actually using the application rather than assuming passing tests meant everything was fine.

This slowed development down.

That was a good thing.

The goal was no longer to produce the most code possible.

The goal was to confidently ship software.

AI Didn't Replace the Developer. It Changed the Developer's Job.

This is probably my biggest takeaway from the entire project.

I wrote dramatically less code manually than I would have a few years ago.

But I didn't have dramatically less responsibility.

In some ways, I had more.

I needed to understand enough about the system to notice when AI was heading in the wrong direction.

I needed to be assertive about architecture instead of letting generated code accumulate wherever convenient.

I needed to recognize security regressions.

I needed to test assumptions.

I needed to reconsider my position when an implementation that looked elegant turned out to be fragile.

And when something broke in production, I couldn't tell the client:

"The AI said it was fixed."

The responsibility was still mine.

Could AI Have Built It in a Week?

Possibly.

At least something that looked like the finished application.

That distinction matters.

Generating 20 modules isn't the same thing as building a dependable 20-module system.

You can move incredibly fast with AI.

But if every new feature creates two regressions, you're borrowing time from your future self.

Eventually, you pay it back through debugging, refactoring, client complaints, longer working hours, and trying to identify which seemingly harmless change caused the latest problem.

Speed is valuable.

Controlled speed is much more valuable.

Three Months Later

The project eventually reached the point where I was genuinely comfortable with it.

It became a large production system with interconnected workflows, financial data, document generation, external sharing, contact management, reporting, and a substantial amount of business logic.

More importantly, the development process itself became disciplined.

AI remained heavily involved.

I didn't respond to the problems by abandoning AI.

I learned to use it differently.

That's the part of AI-assisted development I think gets overlooked.

The interesting question isn't:

"Can AI build an app?"

Of course it can.

The more useful question is:

"Can you manage what AI builds when the application becomes complicated?"

That's where software engineering starts to matter again.

I Documented the Full Experience

I ended up turning the experience into a short case study covering the architecture problems, regressions, security issues, race condition, data loss, testing process, and the workflow I eventually developed between Claude, Codex, and myself.

It's called I Built a 20-Module Business Valuation System With AI.

The title reveals more about the project than I wanted to discuss publicly here, while the case study goes much deeper into what actually happened during those three months.

If you're using AI to build your own product or client software, you can read the full case study here:

I Built a 20-Module Business Valuation System With AI

I used AI to help turn an Excel spreadsheet into a complete 20-module business valuation system. It looked like AI could make the project ridiculously fast...

yaman95.gumroad.com

I'm Ayman Atif, a software developer who has spent years building business software. AI has changed how I work considerably.

It hasn't taken responsibility out of the equation.

If anything, it has made knowing when to intervene more important than ever.

I've Been Programming for 14 Years. I Just Earned My First Microsoft Credential.

Ayman Atif — Sat, 19 Sep 2026 15:10:42 +0000

I’ve been programming for around 14 years.

During all that time, I never really cared about certificates.

I learned by building things.

Web applications. Business software. APIs. Automation tools. Desktop applications. Projects that broke, projects that worked, and projects that forced me to learn things I thought I already understood.

For years, that was enough for me.

Then I decided to try something different.

I gave myself three days to prepare for the Microsoft Applied Skills: Get started with classes, properties, and methods in C# assessment.

I passed.

And it made me reconsider my position on technical credentials.

I also turned the notes and exercises I personally used during those three days into a compact preparation resource for developers who want to follow a similar approach:

https://yaman95.gumroad.com/l/microsoft-applied-skills-classes-methods-properties

But the interesting part isn’t the product.

It’s what happened during those three days.

Why I ignored programming certificates for so long

My reasoning used to be pretty simple:

If I can build software, why do I need a certificate telling people that I can build software?

And there is still some truth to that.

A credential cannot replace experience.

It cannot replace the hours you spend debugging a problem that makes absolutely no sense until you finally find the tiny mistake causing it.

It cannot replace shipping software.

And it definitely cannot turn someone into an experienced developer overnight.

So for most of my career, certificates were completely out of the equation.

I based my argument on practical experience.

Build things. Solve problems. Learn what you need. Repeat.

But there was a weakness in that argument that I hadn't paid enough attention to.

Experience and proof are not the same thing

You might know C#.

You might have used it professionally for years.

But someone looking at your LinkedIn profile, resume, portfolio, or job application doesn't automatically know that.

They have to take your word for it or spend time examining your work.

A credential gives them another signal.

Not proof that you're an amazing developer.

Not proof that you're better than somebody without one.

Just another piece of evidence.

That distinction changed the equation for me.

Microsoft describes Applied Skills credentials as a way to demonstrate practical ability through lab-based assessments involving real tasks rather than relying entirely on traditional knowledge questions.

That caught my attention.

So I decided to test one.

I chose C# classes, properties, and methods

I started with:

Microsoft Applied Skills: Get started with classes, properties, and methods in C#

It's a beginner-level credential focused on fundamental object-oriented C# skills. Microsoft says the assessment evaluates your ability to:

create classes, objects, and types
work with properties
work with methods
call properties and methods

The assessment itself is an interactive lab, and Microsoft currently gives candidates up to two hours to complete it.

You can see the official credential and assessment here:

https://learn.microsoft.com/en-us/credentials/applied-skills/get-started-with-classes-properties-and-methods-in-c-sharp/

I already had years of .NET experience, so my goal wasn't to learn C# from zero.

My goal was different:

Could I organize what I needed to revise, hammer on my weak areas, practice them, and pass the assessment in three days?

So I started preparing.

The three-day preparation

I didn't want to spend three days passively reading documentation.

I wanted something I could actually work through.

So I built my own preparation folder.

As I revised, I organized the concepts I needed, wrote examples, practiced the syntax, and focused on the areas covered by the assessment.

Classes.

Objects.

Constructors.

Properties.

Access modifiers.

Nullable properties.

Methods.

Return values.

Method overloading.

Static classes and members.

Object initializers.

And the small details that are incredibly easy to understand when reading code but surprisingly easy to forget when you have to write the code yourself.

That last part mattered.

There's a big difference between:

“Yeah, I know what that is.”

and:

“Give me an empty editor. I can implement it.”

Microsoft's own study guide reflects that practical scope, covering class creation, property access, nullable/default values, methods, overloads, static classes, object instantiation, and calling methods and properties.

So I practiced.

Then I took the assessment.

And I passed.

The certificate wasn't actually the biggest benefit

This was the counterintuitive part.

I started because I wanted the credential.

But the preparation itself ended up being just as valuable.

When you've programmed for a long time, you accumulate knowledge from everywhere.

Documentation.

Stack Overflow.

Projects.

Coworkers.

Bugs.

Frameworks.

Old codebases.

New codebases.

And increasingly, AI tools.

You can become productive while still having little gaps in fundamentals that you haven't explicitly revisited in years.

Preparing for an assessment forces you to organize that knowledge.

You stop saying:

“I basically know this.”

You have to find out whether you actually do.

That exposed a few things I needed to hammer on.

And that's useful.

Certificates won't replace a portfolio

I still wouldn't tell a developer to collect certificates and neglect everything else.

If I had to weigh a credential against the ability to actually build software, practical ability would take precedence.

Build projects.

Write code.

Learn debugging.

Understand databases.

Learn APIs.

Understand how applications are structured.

Break things.

Fix them.

Ship something.

But it doesn't have to be projects OR credentials.

You can have both.

A project demonstrates what you've built.

Experience demonstrates what you've done professionally.

A credential gives you an external signal that you've demonstrated a defined set of skills.

Those things can complement each other.

Credentials can also give your learning a finish line

This might be my favorite benefit.

“Learn more C#” is a terrible goal.

Where do you stop?

What exactly do you study?

How do you know when you've learned enough?

An assessment gives the learning process boundaries.

You have a defined skill set.

You prepare.

You practice.

You take the assessment.

You pass or you discover where you're weak.

Either outcome gives you information.

Instead of endlessly consuming tutorials, you're working toward something concrete.

For me, that created momentum.

I got the first credential.

Now I want to keep rolling.

Does a Microsoft Applied Skills credential guarantee you a job?

No.

And I wouldn't sell that idea to anyone.

A hiring decision involves experience, communication, technical ability, location, salary, the company, the role, competition, and sometimes plain luck.

One credential doesn't erase that.

But job hunting is rarely about finding one magical thing that gets you hired.

It's about compounding signals.

Your experience.

Your projects.

Your portfolio.

Your GitHub.

Your ability to articulate technical decisions.

Your credentials.

Your communication.

One more credible signal can be useful.

Microsoft itself positions Applied Skills as Microsoft-verified credentials designed to demonstrate specific practical skills, including through interactive, lab-based assessments.

That's the way I'm looking at them now.

Not as a replacement for experience.

As another layer of proof.

Would I pursue more Microsoft credentials?

Yes.

That's probably the biggest change in my position.

After roughly 14 years of programming without paying much attention to certificates, I earned one and immediately understood why they can be useful.

Not because the badge suddenly makes me a better programmer.

It doesn't.

The value was the process:

Choose a skill → revise it → practice it → identify gaps → prove it → move forward.

That's a learning loop I can repeat.

And I intend to.

If you're preparing for the same C# assessment

During my three-day preparation, I created the material for myself first.

It wasn't originally some grand product idea.

It was my prep folder.

After passing, I realized someone else preparing for the exact same assessment might find it useful.

So I cleaned it up and turned it into a focused preparation resource:

C# Classes, Properties & Methods: My 3-Day Microsoft Applied Skills Prep

It follows the concepts I revised before successfully completing the Microsoft Applied Skills assessment, with explanations, C# examples, and exercises.

It's not a shortcut around learning the material.

It's the material I used to make my own revision more focused.

You can check it out here:

https://yaman95.gumroad.com/l/microsoft-applied-skills-classes-methods-properties

And whether you use my notes or prepare completely on your own, I'd recommend giving the assessment a shot if these are skills you're currently learning.

Three days ago, I had never earned a Microsoft credential.

Now I have my first one.

Time to work toward the next.

I’ve Written C# for 10+ Years. These Are the Fundamentals I Still Revisit.

Ayman Atif — Thu, 17 Sep 2026 21:23:10 +0000

After more than 10 years of writing C#, I still look things up.

Not obscure reflection APIs.

Not some forgotten compiler flag.

Fundamentals.

The difference between const and readonly.

What exactly happens when I pass a reference type to a method.

Whether a LINQ query has actually executed yet.

What lifetime a dependency should have.

What happens to an exception inside an asynchronous operation.

Things I learned years ago.

Early in my career, I thought becoming an experienced developer meant eventually reaching a point where these questions disappeared.

The opposite happened.

The longer I worked with production software, the more I realized that a surprising number of difficult bugs come down to simple concepts behaving exactly as designed.

You just misunderstood the design.

I’m Ayman Atif, a software engineer with more than 10 years of experience building business software, including CRM systems, financial applications, APIs, automation tools, reporting systems, and other production applications.

C# and .NET have been a major part of that journey.

You can see some of the software I’ve worked on and more about my background on my portfolio:

Ayman Atif — Software Engineer

These are some of the C# fundamentals I still revisit.

Not because I forgot how to write C#.

Because understanding them properly matters much more once the code has to survive production.

1. Value Types vs. Reference Types

Every C# developer learns this fairly early.

Value types contain their value.

Reference types contain a reference to an object.

Easy.

Until code like this appears:

var customer = new Customer
{
    Name = "John"
};

UpdateCustomer(customer);

Console.WriteLine(customer.Name);

void UpdateCustomer(Customer customer)
{
    customer.Name = "Ayman";
}

The output is:

Ayman

That surprises almost nobody with C# experience.

But change the method slightly:

void UpdateCustomer(Customer customer)
{
    customer = new Customer
    {
        Name = "Ayman"
    };
}

Now the original object hasn't been replaced.

Why?

Because the reference itself was passed by value.

The method received a copy of that reference.

Both references initially pointed to the same object. Reassigning the local copy doesn't change the caller's variable.

That distinction sounds academic when you're learning C#.

It stops being academic when you're debugging mutation across a large application.

The useful question isn't simply:

Is this a class or a struct?

It's:

What exactly is being copied, and what exactly can this code mutate?

That question has saved me considerably more time than memorizing definitions.

2. `const` vs. `readonly`

This is another one that looks almost too basic to revisit.

public const int MaxRetries = 3;

versus:

public readonly int MaxRetries;

A const value is known at compile time and is implicitly static.

A readonly field can be assigned when declared or inside a constructor.

That means this is perfectly valid:

public class RetryPolicy
{
    public readonly int MaxRetries;

    public RetryPolicy(int maxRetries)
    {
        MaxRetries = maxRetries;
    }
}

But there's another reason I pay attention to const, especially when libraries or multiple assemblies are involved.

Constants can effectively be embedded into consuming code at compile time.

Change a public constant in one assembly and an already-compiled consumer may continue using the old value until it is recompiled.

That's the kind of detail that doesn't matter much in a console exercise.

Across independently deployed components, it can matter a lot.

The fundamental didn't change.

The context did.

3. `var` Is Not `dynamic`

I still see these mentally grouped together because both can make the declared type less obvious when reading a line of code.

But they solve completely different problems.

var customer = GetCustomer();

The compiler still knows the type of customer.

This:

dynamic customer = GetCustomer();

is different.

Certain type checks are deferred until runtime.

With var, this fails at compile time:

var number = 10;
number = "ten";

With dynamic, this is allowed:

dynamic number = 10;
number = "ten";

That flexibility comes with a tradeoff.

You are moving some protection from compile time to runtime.

var is mostly about letting the compiler infer a type.

dynamic changes how operations on that value are resolved.

Small distinction.

Very different consequences.

4. `ref`, `out`, and `in`

These keywords are easy to memorize and surprisingly easy to become fuzzy about when you don't use them regularly.

I periodically revisit them.

ref passes a variable by reference and expects it to already be initialized.

void Increment(ref int number)
{
    number++;
}

out also passes by reference, but the called method must assign a value before returning.

bool TryGetAge(string input, out int age)
{
    return int.TryParse(input, out age);
}

in passes an argument by reference while preventing the method from assigning to the parameter.

void Process(in LargeStruct data)
{
    // data cannot be reassigned here
}

The syntax isn't the interesting part.

The interesting part is recognizing what these keywords communicate about ownership, mutation, and intent.

Most code doesn't need them.

That's exactly why they're worth revisiting before using them casually.

5. LINQ: When Does This Code Actually Run?

LINQ is one of my favorite parts of C#.

It is also very easy to write code that looks simpler than what it actually does.

Consider:

var activeCustomers = customers
    .Where(x => x.IsActive);

Has the filtering happened?

Not necessarily.

Many LINQ operations use deferred execution.

The query may execute when you enumerate it:

foreach (var customer in activeCustomers)
{
    Console.WriteLine(customer.Name);
}

Or when you materialize it:

var result = activeCustomers.ToList();

That difference becomes much more important with Entity Framework Core.

This:

var customers = context.Customers
    .Where(x => x.IsActive);

isn't the same thing as immediately loading every matching customer into memory.

You're building a query.

Then something like:

var customers = await context.Customers
    .Where(x => x.IsActive)
    .ToListAsync();

causes it to execute against the database.

When debugging LINQ or EF Core code, one of my first questions is often:

At what point does this query actually execute?

Then:

How many times does it execute?

Those two questions can expose some nasty performance problems.

6. `async` and `await` Don't Mean "Create Another Thread"

This is probably one of the most important C# fundamentals to understand properly.

I used to mentally associate asynchronous programming much more closely with threads.

That's an easy mental model to fall back on.

But:

await httpClient.GetAsync(url);

does not simply mean:

Create another thread and make it wait for the HTTP request.

For I/O-bound work, the whole point is that a thread doesn't need to sit there blocked while the external operation completes.

When the operation finishes, execution can continue.

That's incredibly important for server applications.

Imagine an ASP.NET Core API handling hundreds of requests that are all waiting for databases, HTTP APIs, file operations, or other I/O.

Blocking threads while they wait can eat up resources quickly.

Asynchronous I/O allows those resources to be used more effectively.

But there is another lesson here:

Making a method async doesn't magically make the application scalable.

If you write:

var result = SomeAsyncOperation().Result;

or:

SomeAsyncOperation().Wait();

you are blocking again.

Understanding why async works matters much more than knowing where to type await.

7. `IDisposable` and `using`

I learned using a long time ago.

I appreciate it much more now.

using var stream = new FileStream(
    path,
    FileMode.Open);

When the scope ends, Dispose() is called.

Simple.

But the underlying lesson is about resource ownership.

Some objects represent resources that shouldn't simply be left for garbage collection to eventually deal with.

Files.

Streams.

Database-related resources.

Network resources.

Native handles.

And plenty of other things.

Modern C# makes the syntax extremely clean:

using var connection = CreateConnection();

The syntax is almost boring.

The responsibility behind it isn't.

When working with something disposable, I want to know:

Who owns this resource?

Who is responsible for disposing it?

That becomes especially important once dependency injection enters the equation.

8. Dependency Injection Lifetimes

If you work with ASP.NET Core, you've probably seen these:

services.AddTransient<IService, Service>();
services.AddScoped<IService, Service>();
services.AddSingleton<IService, Service>();

It's tempting to memorize them as:

Transient = always new
Scoped = once per request
Singleton = one

That's a useful starting point.

It isn't enough.

The real question is:

How long should this object live, and what does it depend on?

A singleton depending on state that belongs to an individual request should immediately make you suspicious.

A service holding mutable shared state needs careful thought.

An Entity Framework DbContext has lifetime expectations of its own.

These problems often don't look dramatic in code.

The registrations might occupy three lines in Program.cs.

The bug can appear somewhere completely different.

That's why I revisit service lifetimes instead of assuming that because I've used dependency injection for years, every lifetime decision is obvious.

9. Entity Framework Core Tracking

EF Core makes database work pleasantly simple.

Sometimes too simple.

You can write:

var customers = await context.Customers
    .ToListAsync();

and move on.

But what is EF Core doing with those entities afterward?

By default, queries returning entities are generally tracking them.

That's useful when you intend to modify them and save the changes.

If you're loading data purely for reading, tracking may be unnecessary.

That's where something like this becomes useful:

var customers = await context.Customers
    .AsNoTracking()
    .ToListAsync();

I'm not suggesting throwing AsNoTracking() onto every query.

That would just replace one habit with another.

The point is understanding what the framework is doing for you.

Abstractions are useful because they hide complexity.

Experienced developers still need to know enough about the hidden complexity to recognize when it matters.

10. Exceptions: Catching Everything Isn't Defensive Programming

This looks safe:

try
{
    ProcessOrder();
}
catch (Exception)
{
}

It isn't.

You've taken an error and made it invisible.

A slightly more sophisticated version isn't necessarily much better:

try
{
    ProcessOrder();
}
catch (Exception ex)
{
    Console.WriteLine(ex.Message);
}

What happens now?

Can the application continue safely?

Should the operation be retried?

Should the caller know it failed?

Should it be logged?

Is this actually the correct layer to handle the exception?

Catching an exception should have a reason.

Sometimes the correct decision is to handle it.

Sometimes it's to translate it into something meaningful at an application boundary.

Sometimes it's to log it.

And sometimes the correct decision is to let it propagate.

I don't base exception handling on:

Can this throw?

I prefer:

Can this layer do something meaningful if it throws?

That produces very different code.

11. Collections Are Part of Your Design

Need several objects?

Use List<T>.

That's often perfectly fine.

But not always.

If you're repeatedly checking whether something exists:

if (items.Contains(id))
{
    // ...
}

then the choice between something like a List<T> and a HashSet<T> can become important as the collection grows.

If you're constantly retrieving values by key, a Dictionary<TKey, TValue> may better represent the problem.

The data structure communicates something about the operation you care about.

A list says sequence.

A dictionary says lookup by key.

A set says uniqueness and membership.

You don't need to obsess over theoretical complexity every time you create a collection.

But once data grows or an operation sits inside a hot loop, choosing the right structure can change the equation considerably.

12. `static` Deserves More Thought Than It Gets

static looks harmless.

Sometimes it is exactly what you need.

But static state can quietly create coupling.

Consider:

public static class CurrentUser
{
    public static int Id { get; set; }
}

That might look convenient in a tiny application.

Now introduce concurrent users.

Tests.

Parallel execution.

Different request contexts.

Suddenly that convenience needs much more scrutiny.

This doesn't mean static members are bad.

Far from it.

Pure utility functionality can make perfect sense as static behavior.

Constants and genuinely application-wide state have legitimate uses too.

The important distinction is between:

functionality that doesn't require instance state

and

mutable global state that happens to be convenient.

Those are not the same thing.

13. Equality Is More Complicated Than `==`

This is another fundamental that becomes interesting once domain models become more complicated.

What does it mean for two objects to be equal?

var customer1 = new Customer
{
    Id = 10,
    Name = "Ayman"
};

var customer2 = new Customer
{
    Id = 10,
    Name = "Ayman"
};

Are these equal?

They contain the same values.

But they're two separate instances.

Depending on the type and how equality is implemented, your answer may differ.

Then records enter the picture:

public record Customer(int Id, string Name);

Records give you value-oriented equality semantics that can be extremely useful for certain models.

The broader lesson isn't "use records."

It's to define what equality actually means for the thing you're modeling.

Two references being different doesn't necessarily mean the domain considers the values different.

And two references pointing to the same object doesn't necessarily tell you anything useful about business identity.

14. Nullability Is Better When You Treat It as Design Information

Nullable reference types were one of those C# additions that initially looked like extra compiler noise to some developers.

But consider:

string name;

versus:

string? name;

That ? communicates something.

The absence of a value is expected.

That's not merely a compiler detail.

It's information about your model.

If a customer must always have an email address, model that intentionally.

If a middle name is optional, model that intentionally too.

The goal isn't to silence every nullable warning as quickly as possible.

The goal is to make the compiler help you identify places where your assumptions about missing values may be wrong.

The more accurately the type system describes reality, the less defensive guessing the rest of your code needs.

The Pattern I Keep Seeing

After years of C# and .NET development, I've noticed something.

Junior developers often worry about not knowing enough advanced features.

Experienced developers often worry about misunderstanding simple ones.

That's a very different concern.

A clever language feature might save you five lines of code.

A misunderstanding of object lifetime, async behavior, query execution, mutation, equality, or resource ownership can create a bug that takes hours to find.

Sometimes days.

Production software has repeatedly hammered that lesson into me.

The code that causes the worst problems isn't always complicated.

Sometimes it's completely ordinary code built on one incorrect assumption.

You Don't Outgrow the Fundamentals

Ten years ago, revisiting C# fundamentals would have felt like going backward.

Today I see it differently.

I don't need to prove that I remember every detail of the language without checking documentation.

I need to make good engineering decisions.

Sometimes that means opening the documentation.

Sometimes it means writing a tiny console application to verify behavior.

Sometimes it means reconsidering my position on a pattern I've used for years.

And sometimes it means returning to something I supposedly "learned" a decade ago and realizing I understand it differently now.

That's not going backward.

That's what experience does.

You stop collecting syntax.

You start understanding consequences.

And in a language as mature and capable as C#, there is always another layer underneath something you thought you already knew.

I'm Ayman Atif, a software engineer with 10+ years of experience building and maintaining production software with C#, .NET, Python, SQL, APIs, automation, financial systems, CRM platforms, and business applications.

I write about lessons from building real software, including the mistakes, architecture decisions, performance problems, and fundamentals that become more important as applications grow.

Portfolio and projects:
Ayman Atif — Software Engineer

How I Learned Odoo Development From Scratch and Got the Job in 30 Days

Ayman Atif — Tue, 15 Sep 2026 15:40:21 +0000

In 2024, I applied for an Odoo Developer role even though I had never worked with Odoo before.

Not “a little experience.”

Zero.

I was already a software engineer with more than 10 years of experience building business software, primarily with .NET, alongside Python, APIs, automation, CRM systems, financial software, and production web applications.

My name is Ayman Atif, and I have been developing software since 2014.

You can see more of my work and background on my portfolio:

https://ayman-atif.vercel.app/

At the time, I was looking for a second income stream and applying for remote development jobs.

Then I found a job post asking for:

Python
PostgreSQL
Odoo

Python was familiar territory.

PostgreSQL was not a problem either.

Odoo was the strange part.

I had never developed an Odoo module.

I had never built an Odoo application.

I had barely paid attention to the platform before that job post appeared.

Normally, that sounds like a job you skip.

I applied anyway.

That decision eventually led to one of the most useful lessons I have learned in my software career:

You do not always need to know the technology before you apply. Sometimes you need to prove that you know how to learn it.

This article explains exactly how I approached that month, what I studied, what I deliberately skipped, and the system I now use whenever I need to learn an unfamiliar technology quickly.

I Did Not Pretend to Be an Odoo Developer

This part matters.

I did not rewrite my resume and pretend that I had Odoo experience.

I did not exaggerate my background.

I did not create a fake portfolio project and present myself as something I was not.

Instead, I based my argument on something I could actually defend.

I told the employer that I had experience transitioning into unfamiliar technical areas quickly.

And I backed that claim with a real example.

Before this Odoo opportunity, I had worked on a news aggregation system that automatically transformed news content into videos.

That project involved AI-related development.

At the time, I did not come from an AI background.

I had to understand an unfamiliar technical area, experiment, solve practical problems, and contribute to a working system.

That was the evidence behind my claim.

My message was essentially:

I may not know Odoo yet, but I have already demonstrated that I can enter unfamiliar technical territory and become productive.

The letter was not particularly fancy.

It was not full of corporate language.

It was just honest.

And apparently, that was enough to get their attention.

The Employer Challenged My Claim

Eventually, they came back with a simple challenge.

If I believed I could transition into Odoo quickly, I had to prove it.

I was given roughly one month to learn the basics of Odoo development and build a project.

The project was an optical module for a clinic.

That changed the equation completely.

I no longer needed to convince someone with words.

I had a real technical target.

Thirty days.

A technology I did not know.

A real project at the end.

This was exactly the kind of situation where spending three weeks preparing to start would have been a mistake.

So I did not approach it like a traditional course.

I approached it like a developer entering an unfamiliar codebase.

Why I Did Not Start With a Long Odoo Course

There is nothing inherently wrong with courses.

The problem was time.

I did not want to spend several hours watching someone explain how a manifest file works before I had even touched one.

I needed context first.

So instead of making tutorials the center of my learning process, I went directly to existing Odoo modules.

I opened GitHub repositories.

I looked at small modules.

I scanned their structure.

I wanted to see what kept repeating.

Very quickly, certain pieces appeared again and again:

manifest files
models
XML views
module initialization
Python classes
fields
actions
menus

That gave me a map.

The important difference in my case was the order.

I did not try to understand everything before writing anything.

I touched the code first.

My Learning Loop Was Simple

My basic loop looked like this:

Inspect → Rebuild → Modify → Break → Debug → Repeat

I would open a small module and inspect how it was structured.

Then I would rebuild part of it.

Then I would change something.

Then something would inevitably break.

And that failure forced me to understand the part I had just touched.

This was much more useful to me than passively watching hours of content.

There is a counterintuitive part here.

At the beginning, I memorized syntax.

Sometimes almost word for word.

Not because memorization was the end goal.

Because it reduced friction.

When you enter a completely unfamiliar framework, everything feels expensive.

You forget the file names.

You forget where things belong.

You forget the syntax.

You forget what calls what.

If you memorize some of those mechanical pieces early, your brain has more room to understand the actual structure later.

Understanding gradually replaced memorization.

I Still Used YouTube, Just Not as the Main Learning Method

I was also watching an Odoo development playlist.

The playlist was titled:

How To Configure Odoo15 With Pycharm || Odoo 15 Development Tutorials

It contained around 189 videos.

I watched somewhere around 60 of them.

I did not sit down and consume all 189 videos before building anything.

That would have defeated the purpose.

I typically watched around two videos per day.

Then I reinforced the concepts by working directly with modules.

That distinction matters.

Watching was supporting the work.

The work was not supporting the watching.

A lot of developers accidentally reverse that.

They spend days collecting information, then tell themselves they will build something once they “know enough.”

You can easily get stuck there.

What I Focused on First

I deliberately narrowed the scope.

I did not try to become an Odoo expert.

I needed to become useful.

So I worked through the structure in roughly this order:

Manifest Files

I wanted to understand what defined a module.

What did Odoo need in order to recognize it?

What information belonged in the manifest?

What did dependencies look like?

What resources were loaded?

I did not need deep architectural knowledge yet.

I needed orientation.

Models

Once the module structure felt less foreign, I moved into models.

This part felt more natural because I already had years of programming experience.

Classes, fields, business logic, relational data, validation, and procedural problem solving were not new concepts.

The syntax was new.

The thinking was not.

That distinction is incredibly important when learning a new stack.

XML Views

Then came the UI structure.

Forms.

Lists.

Menus.

Actions.

Layouts.

XML initially created more friction because it was tied closely to Odoo’s conventions.

But repetition made it predictable.

Modification

Once I understood a small module, I changed it.

Rename a field.

Add something.

Remove something.

Change a view.

Alter behavior.

This was where the learning became real.

Debugging

Breaking the module was often more educational than successfully copying it.

When something failed, I had to follow the argument through.

Why did it fail?

Was the model wrong?

Was the XML wrong?

Was the module not loaded correctly?

Was the field missing?

Was the dependency wrong?

Debugging turned passive familiarity into usable knowledge.

My Existing Programming Experience Did Most of the Heavy Lifting

This is one reason I do not think developers should mentally reset themselves to zero when switching technologies.

Your previous experience is not out of the equation.

It transfers.

I already understood:

procedural programming
object-oriented programming
databases
debugging
business logic
APIs
application structure
data flow
software maintenance
production constraints

I was learning a framework, not relearning how computers work.

That dramatically shortened the learning curve.

The more fundamentals you already understand, the less a new framework feels like starting over.

My Daily Schedule

My schedule during that period was fairly structured.

I worked from around:

9:00 AM to 6:00 PM

with approximately a one-hour break.

Outside of the core work period, I kept reinforcing what I was learning.

After I got the role, the intensity increased.

For roughly the next month, I was doing something close to:

8 hours working

plus

4 additional hours learning and practicing

That is around 12 hours a day connected to the new technology.

I would not recommend that schedule indefinitely.

It is difficult to sustain.

But for a short transition period, it accelerated the feedback loop enormously.

Every day I was seeing real problems at work, then learning the concepts behind them afterward.

Work generated questions.

Study answered them.

The next day generated better questions.

That compounded quickly.

What Happened After the First Month

At the end of the month, I completed the challenge and earned the role.

But getting the job was not the end of the learning process.

That was really when the useful learning started.

During the first month, I was mainly getting comfortable with:

module structure
XML
models
views
common patterns

By the second month, I was moving beyond basic XML customization.

I was able to work with Odoo OWL and build more custom controls.

That mattered because it marked a transition.

At the beginning, I was mostly learning how Odoo wanted things done.

Later, I could start bending the framework toward actual requirements.

That is a much better definition of progress than counting tutorial hours.

The Goal Was Never to Become an Expert in 30 Days

This is where these stories often become misleading.

I did not become an Odoo expert in one month.

That is not the lesson.

I became useful enough to prove that I could do the work.

Those are very different claims.

Being useful means you can:

understand the basic structure
navigate the framework
build something real
diagnose common failures
research unfamiliar problems
make progress without constant supervision

Expertise takes much longer.

That is much closer to how I think developers should approach unfamiliar technology.

Do not ask:

How do I master this?

Ask:

What would make me useful with this?

How I Would Learn an Unfamiliar Technology Today

If I had to repeat the same experience with another framework, platform, or programming language, I would use almost the same process.

Day 1 to 3: Understand the Shape

Do not go deep.

Figure out:

project structure
entry points
configuration
data model
common terminology
how the smallest working example looks

Your goal is orientation.

Day 4 to 7: Read Tiny Real Projects

Find small repositories.

Avoid huge production codebases at first.

Look for repetition.

What files always appear?

What patterns repeat?

Where does logic live?

Where does configuration live?

Week 2: Rebuild Examples

Stop reading so much.

Build.

Recreate small features without constantly copying.

When you forget something, look it up.

Then continue.

Week 3: Modify Aggressively

Take things that work and change them.

Add fields.

Remove features.

Change behaviors.

Swap components.

Push the framework outside the exact tutorial scenario.

Week 4: Build One Real Project

Pick something with clear requirements.

Not a demo.

Not “hello world.”

Something that forces several concepts to work together.

That project is where your fragmented knowledge starts becoming a system.

Do Not Confuse Learning With Content Consumption

One of the biggest traps in software development is feeling productive because you are consuming technical material.

Ten hours of video can feel substantial.

But ask yourself:

Could you build something without the instructor?

Could you explain why the project is structured that way?

Could you diagnose it when it breaks?

Could you change the requirement?

If not, you are probably still at the recognition stage.

Recognition feels like understanding because the code looks familiar.

But producing it independently is different.

This is why I prefer a build-heavy learning method.

The code exposes what you actually know.

Read Existing Code Earlier

This is probably the biggest habit I would recommend.

A lot of developers delay reading other people's code because it feels intimidating.

I think that is backwards.

Existing repositories show you things that tutorials often hide:

real naming conventions
real file structure
repetition
workarounds
patterns
configuration
boring glue code

That boring code is often exactly what you need to become productive.

Framework fluency comes from recognizing its patterns repeatedly.

What About AI?

My original Odoo transition happened before AI coding assistants became as deeply integrated into everyday development as they are now.

Today, learning the same framework would probably be faster.

But there is also a new risk.

AI can remove the struggle that produces understanding.

If every error goes directly into an AI assistant and you paste back the fix, you may ship faster while learning less.

I would use AI today, but I would keep one boundary:

Never let it remove the need to understand the change you are making.

Ask it to explain.

Ask it to compare approaches.

Ask it where to look.

Ask it why something failed.

But if you cannot explain the final solution yourself, you have probably outsourced too much of the learning.

A Better Way to Think About Technology Switching

Developers often identify themselves too tightly with one stack.

“I am a .NET developer.”

“I am a Java developer.”

“I am a React developer.”

There is nothing wrong with specialization.

I still have deep experience with .NET.

But your programming language is not your entire professional identity.

The more experienced you become, the more your value comes from things that survive stack changes:

debugging
decomposition
architecture
data modeling
reasoning
communication
requirement analysis
tradeoffs
maintainability
learning speed

That is why experienced developers can sometimes transition faster than they expect.

The syntax changes.

The underlying problems are often familiar.

Should You Apply for Jobs Where You Do Not Match Every Requirement?

Sometimes, yes.

But there is a difference between being underqualified and being dishonest.

I would still apply when:

I understand the underlying engineering domain
the missing skill is learnable
I have evidence of learning similar things before
I can articulate how my existing skills transfer
I am willing to prove the claim

I would not claim experience I do not have.

That distinction probably helped me more than pretending would have.

I was not selling Odoo expertise.

I was selling adaptability.

And then I had to pay up by actually learning it.

The Repeatable Learning System

If I reduce the entire experience to one system, it is this:

Find the smallest real structure
Inspect existing examples
Memorize enough syntax to remove friction
Rebuild examples yourself
Modify them
Break them
Debug them
Build one real project
Keep learning after you become employable

That is the part I still use.

Not Odoo specifically.

The learning process.

I Turned This Experience Into a Practical Guide

I recently turned the full experience into a short practical PDF:

I Got an Odoo Job With Zero Odoo Experience

It includes the learning system, the 30-day structure, how I approached unfamiliar code, how I used existing programming experience, what happened after I got the role, and how to adapt the same process to another technology.

You can find it here:

https://yaman95.gumroad.com/l/i-got-odoo-job-with-zero-odoo-experience

The guide is not about promising that someone can become an expert in 30 days.

It is about becoming useful quickly enough to start doing real work, then continuing to learn from the work itself.

About Ayman Atif

I am Ayman Atif, a software engineer from Morocco with more than 10 years of experience building business software.

I have worked primarily with .NET and C#, alongside Python, Flask, Django, PostgreSQL, REST APIs, automation, CRM systems, financial applications, Android development, and production business platforms.

My work focuses heavily on understanding business problems, designing practical software around them, improving existing systems, and maintaining applications after they reach production.

You can see my portfolio, selected projects, services, and other technical writing here:

Ayman Atif, Software Engineer

https://ayman-atif.vercel.app/

If you are learning a new technology, switching stacks, or trying to become productive in an unfamiliar framework, I hope this experience gives you a useful way to approach it.

Do not wait until everything feels familiar.

Familiarity often comes after you start building.

10 Years of Building Business Software: What Production Systems Taught Me That Tutorials Didn’t

Ayman Atif — Sat, 12 Sep 2026 13:53:06 +0000

I started developing software in 2014.

Back then, like most developers, I spent a lot of time thinking about code.

Was this the right design pattern? Was there a cleaner way to write this method? Should this logic live in another class? Was I using the framework correctly?

Those questions matter. I still ask them.

But after more than 10 years of building software, I have learned that they are rarely the hardest questions.

The difficult part starts when software leaves your development environment and becomes something a business actually depends on.

A feature can work perfectly and still be the wrong feature.

A database query can be fine with 500 rows and become a problem with 500,000.

A workflow that makes perfect sense to a developer can frustrate the people who have to use it every day.

And a system that looks well designed today can become surprisingly difficult to change two years from now.

Those are lessons that are difficult to learn from tutorials.

You learn them by building, maintaining, breaking, fixing and improving real software.

The Business Problem Comes Before the Technology

Earlier in my career, I was much more likely to start thinking about implementation as soon as someone described a feature.

Today, I try to understand the process first.

What is the person actually trying to accomplish?

What are they doing manually today?

Where does the information come from?

Who is responsible for it?

What happens when something goes wrong?

What part of the process is actually expensive or frustrating?

Sometimes a client asks for a feature, but after following the workflow through, you realize that the requested feature is solving the symptom rather than the underlying problem.

That changes the equation.

The job is no longer simply:

Build what was requested.

It becomes:

Understand why it was requested, then determine what should actually be built.

This is especially important with business software because existing processes often contain years of knowledge.

A spreadsheet, for example, might look messy from an engineering perspective. But hidden inside that spreadsheet can be calculations, exceptions and business rules that employees have developed over years.

Replacing it with software without understanding those rules can make the new system worse than the spreadsheet it replaced.

Production Changes Your Definition of "Working"

During development, it is easy to define success like this:

The feature works.

In production, that definition is nowhere near enough.

Does it work when several people use it at the same time?

Does it still work when the database becomes much larger?

What happens when an external service fails?

What happens when someone uploads unexpected data?

Can you understand what happened when something breaks?

Can another developer safely change the code six months later?

Can the business recover if something goes wrong?

A production system has responsibilities that a demo does not.

I have worked on business applications involving financial data, document generation, reporting, CRM workflows, automation, APIs and complex database operations.

The bugs that take the most time are often not obvious programming mistakes.

They appear because several individually reasonable decisions interact in an unexpected way.

That is one reason I have become much more interested in system behavior than isolated pieces of code.

Performance Problems Are Often System Problems

When an application becomes slow, the tempting response is to look for slow code.

Sometimes that is exactly the problem.

Often it isn't.

The slowdown might involve database queries, indexes, repeated API calls, unnecessary browser work, server memory, large documents, network latency or several of those things compounding each other.

Optimizing one function might accomplish almost nothing.

I learned to trace the entire path instead.

What happens from the moment the user clicks the button until the result appears?

Where is time actually being spent?

What data is being transferred?

What work is repeated?

What resources are constrained?

You have to follow the argument through instead of assuming that the most visible part of the application is responsible.

This mindset has saved me from "optimizing" code that wasn't causing the problem in the first place.

Existing Software Deserves Investigation Before a Rewrite

Developers love clean starts.

There is something satisfying about looking at an old application and imagining how much better it would be if we rebuilt everything using a modern architecture.

Sometimes a rewrite is justified.

But I have become much more cautious about recommending one.

Old software contains knowledge.

It contains strange conditions because somebody encountered a strange situation five years ago.

It contains validation rules because something once went wrong.

It contains workflows that employees have quietly adapted to.

Some of the code may genuinely be bad. But deleting code is much easier than recovering the business knowledge that was encoded inside it.

When I inherit an existing application, I prefer to understand it first.

Find the fragile areas.

Identify the dependencies.

Understand the data.

Fix the highest-risk problems.

Improve boundaries gradually.

Then decide whether replacing larger parts of the system is actually worth it.

A rewrite should be an engineering decision, not an emotional reaction to ugly code.

Automation Is Mostly About Understanding Repetition

Automation is another area where the programming is often the easy part.

The real work is understanding the process well enough to automate it safely.

Imagine someone repeatedly:

opens a spreadsheet,

copies information from another system,

checks several conditions,

generates a document,

sends an email,

and updates a status somewhere else.

You could automate those steps.

But first you need to know why each step exists.

Which decisions require human judgment?

Which rules are consistent?

What happens when information is missing?

What should happen when something fails halfway through?

What needs to be logged?

Can the process be resumed?

Good automation does not simply make something faster.

It makes a process more structured, repeatable and easier to inspect.

That distinction has shaped the way I approach business process automation today.

Maintainability Becomes Very Real When You Maintain Your Own Code

There is a particular kind of humility that comes from opening code you wrote two years ago.

At the time, everything seemed obvious.

Two years later, you might stare at it wondering why anyone would structure something that way.

Then you check the Git history.

Oh.

It was you.

That experience changes how you think about maintainability.

Clean code is not about making code look clever.

Architecture is not about using as many abstractions as possible.

Patterns are not achievements by themselves.

The purpose is to make future changes safer and easier to reason about.

Sometimes an abstraction helps.

Sometimes three straightforward functions are better than an elaborate hierarchy.

Sometimes duplication is temporarily less dangerous than coupling two things that only happen to look similar today.

The longer I work in software, the less interested I become in rules that say you should "always" structure code a particular way.

Context matters.

Simple Software Is Usually Hard to Build

One of the most counterintuitive lessons I have learned is that simple software can require a lot of engineering.

Users should not need to understand your database structure.

They should not need to know that three APIs are involved.

They should not care that a document is assembled from multiple sources.

They want to click something and have the correct result appear.

Making that experience simple often means handling considerable complexity behind the scenes.

The temptation is to cut corners and expose some of that complexity to the user.

But every technical responsibility you push onto users makes the system harder for the business to operate.

Good business software absorbs complexity instead of distributing it.

Communication Is an Engineering Skill

Ten years ago, if you had asked me what makes someone a strong software developer, I probably would have based my answer mostly on technical ability.

Today, I would revise my position.

Technical skill still matters enormously, but professional software development also requires being able to articulate tradeoffs.

Why are we building this?

Why this approach?

What happens if we don't fix this problem?

Why will this take longer than expected?

What are we giving up by choosing option A instead of option B?

Engineers constantly weigh speed against maintainability, flexibility against complexity, and short-term requirements against long-term consequences.

If those tradeoffs remain inside the developer's head, the business cannot participate in the decision.

Being able to explain them clearly is part of the engineering work.

The Best Technical Decision Depends on the Business

I work primarily with .NET and Python today.

Both are powerful ecosystems, but I don't believe the technology should take precedence over the problem.

Sometimes ASP.NET Core is an excellent foundation for a long-lived business application.

Sometimes Python and Flask let you build a focused internal system quickly and maintain it comfortably.

Sometimes the correct solution is not a new application at all.

Maybe an existing process can be improved.

Maybe a small automation is enough.

Maybe the spreadsheet should stay, but the repetitive work around it should disappear.

Good engineering is not about finding opportunities to use your favorite technology.

It is about choosing an appropriate amount of technology for the problem.

What I Care About After 10+ Years

My definition of software engineering has changed considerably since I started in 2014.

I still care about code quality.

I still enjoy learning frameworks, improving architecture and solving difficult technical problems.

But those things now sit inside a larger picture.

I care about understanding why the software exists.

I care about what happens when it reaches production.

I care about whether someone can safely maintain it.

I care about whether it remains useful when the business changes.

And I care about whether the technology is actually making someone's work easier.

That is the side of software engineering I find most interesting today.

I write more about these lessons in my software engineering blog, where I cover .NET, backend engineering, architecture decisions, production constraints, technical interviews and lessons from building real systems.

Read my software engineering blog:
https://ayman-atif.vercel.app/blog/

If you're dealing with a business process that still relies heavily on spreadsheets, an application that has become difficult to maintain, or an idea that needs a technical plan, you can also learn more about my work here:

Ayman Atif — Software Engineer
https://ayman-atif.vercel.app/

DEV Community: Ayman Atif

The Screen Looked Finished. Then I Clicked Save Twice.

Where I learned this

Build with a two-AI team

The six-step loop: Inspect, Plan, Approve, Implement, Verify, Document

Four habits that keep a project steady

The full field guide

The Test Your AI Rewrote to Go Green

The feature worked—or did it?

When the proposed fix changes the test

Green doesn't always mean correct

What I take from this

One rule I try to follow

I'm a Software Engineer, and I'm Choosing to Build With AI. Here's Why.

I'm a Software Engineer, and I'm Choosing to Build With AI. Here's Why.

We need to stop treating AI as something developers must either love or hate

Writing code is only part of building software

I'm working on something called Building Real Software with AI

Why start with a PDF?

Who am I building this for?

I'm not trying to predict the future of software development

The Prompt Engineering Mistake That Turns a Small Feature Into a Big Refactor

The mistake: treating implementation as the first step

Change the prompt, not just the wording

Why this matters beyond prompt engineering

A practical rule I use

Migrating a Microsoft Access Database to a Web App: What Moving an Agency’s CRM Taught Me

Why businesses end up here

The part everyone underestimates: relationships

Your data is messier than you think

Let the person who knows the data decide

Build the new system for the people who'll use it

Three builds, one change in thinking

If you're planning your own Access migration

Where to see more

Publishing notes (not part of the article)

I Rebuilt a CRM 3 Times Because I Solved the Wrong Problem

I built it for developers, not users

The real problem was hidden in the old data

Names and emails weren't enough

The solution: matching rules and human verification

Why did I rebuild it three times?

I now think about the problem before the technology

How I Rebuilt an Excel-Like Web App After the First Architecture Failed

The First Approach

Version History Exposed the Architecture Problem

I Rebuilt the Data Model Around JSON

Why JSON Fit This Problem Better

Undo and Redo Became a Versioning Problem

The Lesson Was Not "JSON Is Better Than SQL"

Sometimes Rebuilding Is Cheaper Than Continuing to Patch

What I Would Do Differently Today

About the Developer

AI Could Build My Client’s App in a Week. Making It Reliable Took Me 3 Months.

AI Could Build My Client’s App in a Week. Making It Reliable Took Me 3 Months.

The First Version Is the Easy Part

A Feature Worked. Something Else Broke.

Then I Found a 20,000-Line File

The Scariest Problem Wasn't Messy Code

AI Also Doesn't Care If Your Product Slowly Loses Its Identity

I Eventually Split the Responsibilities Between AI Models

AI Didn't Replace the Developer. It Changed the Developer's Job.

Could AI Have Built It in a Week?

Three Months Later

I Documented the Full Experience

I Built a 20-Module Business Valuation System With AI

I've Been Programming for 14 Years. I Just Earned My First Microsoft Credential.

Why I ignored programming certificates for so long

Experience and proof are not the same thing

I chose C# classes, properties, and methods

The three-day preparation

The certificate wasn't actually the biggest benefit

Certificates won't replace a portfolio

Credentials can also give your learning a finish line

Does a Microsoft Applied Skills credential guarantee you a job?

Would I pursue more Microsoft credentials?

If you're preparing for the same C# assessment

I’ve Written C# for 10+ Years. These Are the Fundamentals I Still Revisit.

1. Value Types vs. Reference Types

2. const vs. readonly

2. `const` vs. `readonly`

3. `var` Is Not `dynamic`

4. `ref`, `out`, and `in`

6. `async` and `await` Don't Mean "Create Another Thread"

7. `IDisposable` and `using`

12. `static` Deserves More Thought Than It Gets

13. Equality Is More Complicated Than `==`