DEV Community: Ayman Atif

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.Then the real problems started.New features caused regressions. Security policies broke. Unrelated parts of the platform stopped working. Designs became inconsistent. One file grew to more than 20,000 lines. A race condition eventually caused data loss, even after AI confidently suggested the problem had been fixed.This case study explains what happened and how I changed my workflow to get the project under control.I cover how I used Claude for design and implementation, Codex for architecture and review, and automated tests, manual testing, and browser testing to catch problems before they reached the client.The finished system handles business sellability, financial analysis, valuation workflows, CIM and BLI generation, and controlled sharing with sellers, buyers, bankers, and other relevant contacts.It took around three months to reach a result I was comfortable shipping.This is not a prompt collection or a guide promising that AI will build your SaaS overnight.It is my experience building a complex client system with AI, including the mistakes, regressions, architectural problems, security issues, and lessons that came with it.Written by Ayman Atif, software developer.

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/

I Was a .NET Developer. Then My Company Told Me to Learn Android.

Ayman Atif — Fri, 11 Sep 2026 14:10:59 +0000

Java got me into Android development. Kotlin made me stay. Years later, I still build Android apps for fun.

I did not start my career wanting to become an Android developer.

For most of my professional life, I was the .NET guy.

C#, business applications, databases, internal systems, desktop software, APIs. That was the world I knew well.

Then one day, the company I was working for needed an Android application.

There was one small problem.

I did not know Android development.

And at the time, Android meant Java.

So I had to learn it.

Going from C# to Java

Coming from .NET, Java felt familiar enough that I could get moving quickly.

Classes looked familiar.

Interfaces looked familiar.

Object-oriented programming was still object-oriented programming.

But Android itself was completely new territory.

Activities.

Fragments.

XML layouts.

The Android lifecycle.

Permissions.

Adapters.

Intents.

Gradle.

Suddenly, building a button was the easy part. Understanding everything happening around that button was the interesting part.

I remember spending a lot of time trying to understand why an application behaved one way when I launched it normally and another way after Android recreated an activity.

Coming from desktop development, that took some adjustment.

But something unexpected happened.

I started enjoying it.

Android felt different

Most of the software I had built professionally was business software.

CRM systems.

Financial applications.

Reporting systems.

Automation tools.

Software designed to solve operational problems.

I still enjoy building those systems. In fact, they remain a big part of what I do today.

But Android development scratched a different itch.

You build something, install it on a phone, tap the icon, and suddenly your software feels like a physical thing.

It lives in your pocket.

You swipe through it.

You touch it.

You immediately notice whether an interaction feels smooth or annoying.

That feedback loop is addictive.

Android development slowly became something I enjoyed doing even when nobody was asking me to do it.

Then Kotlin showed up

Eventually, Android development started moving toward Kotlin.

At first, I was skeptical.

Java worked.

I already knew Java.

Why introduce another language?

Then I actually started using Kotlin.

And my position changed pretty quickly.

Kotlin removed a surprising amount of ceremony.

Null safety was better.

Data classes were convenient.

Extension functions were useful.

The syntax was cleaner.

Coroutines eventually made asynchronous code much nicer to work with.

Going back to Java after spending enough time with Kotlin started feeling unnecessarily verbose.

Today, if I am starting an Android project, Kotlin is the obvious choice for me.

And once Jetpack Compose matured, Android development became even more enjoyable.

Jetpack Compose changed the experience again

One thing I never particularly loved about traditional Android development was constantly jumping between XML layouts and Java or Kotlin code.

Compose changed that dynamic.

Building UI directly in Kotlin feels much closer to the way I naturally think about an interface.

A screen becomes a composition of components.

State changes.

The UI reacts.

You iterate quickly.

For someone who has spent years building web applications, desktop applications, and business software, Compose feels surprisingly comfortable.

It also made Android one of those technologies I regularly come back to simply because I want to build something.

Not because a client requested it.

Not because my employer needs it.

Just because it is fun.

My latest Android side project

Recently, I wanted to build a resume builder.

Nothing revolutionary.

Just a focused Android application that lets someone create a professional resume without needing an account, a browser, or a complicated setup.

I started with a simple idea.

The user should open the app and immediately understand what to do.

So instead of one giant form, I broke resume creation into steps:

Personal details
Professional summary
Work experience
Education
Skills and additional information
Template selection
Preview and PDF export

You can also jump directly between sections instead of repeatedly pressing Next.

That small detail matters more than it sounds.

Once a resume already exists, users usually know exactly what they want to change.

They should not have to weave through five screens just to edit their education.

The PDF part became the interesting problem

The editor itself was straightforward.

The PDF renderer was where things became more interesting.

A resume looks simple until you have to generate one dynamically.

What happens when an experience description is too long?

What happens when a section starts at the bottom of the page?

Do you split an education entry between two pages?

How do you make the preview match the exported PDF?

How much spacing should exist between sections?

How do you wrap text based on its actual rendered width instead of guessing based on character count?

Those details compound quickly.

I ended up building pagination directly into the PDF renderer so longer resumes can naturally continue onto additional pages.

The preview is also rendered from the same PDF engine used for export.

That means the preview is not pretending to represent the final document.

It is the final document.

I also wanted two very different resume styles

The app currently has two templates.

The first is a clean ATS-oriented resume.

Simple structure.

Easy to scan.

Traditional presentation.

The second is the one I enjoyed building the most.

It is a two-column design with a blue sidebar containing contact details, skills, languages, and certificates.

The main area contains the summary, experience, and education.

Getting that layout to paginate properly was much more interesting than simply drawing a nice-looking page.

A template can look great with perfect demo data and completely fall apart once a real user enters twice as much content.

That is the part of development screenshots rarely show.

The app became something I wanted to release

Originally, this was another Android project I was building because I enjoy Android development.

But once it reached the point where it had:

Local resume storage
Automatic saving
Multiple resumes
Resume duplication
ATS and two-column templates
PDF preview
Automatic text wrapping
Multi-page PDF export
AdMob integration
A proper guided editor

I realized there was no reason to leave it sitting in one of my project folders.

So I packaged the complete Android Studio project.

The source code is now available as Resume Builder Premium.

If you are an Android developer, indie developer, or someone learning Kotlin and Jetpack Compose, you can use it as a starting point instead of rebuilding the entire foundation yourself.

👉 Resume Builder Premium Android Source Code

It is built with Kotlin, Jetpack Compose, Material 3, local JSON persistence, Android's PDF APIs, and Google Mobile Ads.

The idea is simple.

Take the working foundation, change the branding, customize the templates, replace the AdMob IDs, and go from there.

Why I still build Android apps

Android development is not my only area of software development.

Far from it.

I have spent more than a decade working with software, particularly .NET, Python, business applications, financial systems, automation, APIs, databases, and reporting tools.

But Android has remained one of those things I genuinely enjoy.

There is something satisfying about watching an application go from an empty project to something you can hold in your hand.

Maybe that is why I keep coming back to it.

I originally learned Android because a company needed me to.

I kept building Android apps because I liked it.

Sometimes your employer pushing you outside your normal stack ends up introducing you to something you would never have pursued on your own.

That happened to me with Android.

And I am pretty glad it did.

About me

I'm Ayman Atif, a software engineer focused on building practical software for businesses.

Over the years, I've worked on business applications, CRM systems, financial and reporting software, automation tools, APIs, and mobile applications using technologies including .NET, Python, Kotlin, and Java.

If you'd like to see more of my work, projects, and what I build:

👉 Visit my software engineering portfolio

And if you are interested in the Android project discussed in this article:

👉 Get Resume Builder Premium

I’ll probably keep building Android apps whether they become products or not.

At this point, it is partly software development and partly a hobby.

And those are usually the projects I have the most fun building.

Ayman Atif: How I Build Software Around Business Problems

Ayman Atif — Tue, 08 Sep 2026 17:17:03 +0000

I'm Ayman Atif, a freelance .NET and Python software engineer.

I've been building software since 2014, and over the years I've learned something that changed how I approach development:

Businesses don't really need more code. They need their problems solved.

A company rarely says:

“We need an ASP.NET Core API.”

They usually say:

“We're still doing this manually in Excel.”

“Our application has become painfully slow.”

“Nobody understands this old codebase anymore.”

“Every change seems to break something else.”

“We need to automate this process.”

Those are the problems I enjoy solving.

What I do as a freelance software engineer

My work focuses on business software development, .NET development, Python development, and business process automation.

I work with businesses that need someone who can understand the problem, plan the solution, build it, and stay involved after deployment.

That can mean building:

Business web applications
Backend systems and APIs
Internal tools
Dashboards
Automation systems
Data processing pipelines
Document workflows
PDF and Excel processing
Database-driven applications
Existing software improvements

My main technologies include C#, .NET, ASP.NET Core, Python, Flask, Django, SQL, JavaScript, and REST APIs.

But technology is usually not where the project starts.

I start with the business problem

One thing I've become increasingly deliberate about is avoiding the temptation to code immediately.

Before writing the first feature, I want to understand:

What is the business trying to accomplish?

Who uses the system?

What is currently taking too much time?

Where do mistakes happen?

What happens when something goes wrong?

Which parts of the existing system actually need to change?

And perhaps most importantly:

What problem are we really trying to solve?

Sometimes the answer is a new application.

Sometimes it's an automation workflow.

Sometimes it's a database optimization.

Sometimes it's a relatively small change to an existing system.

And sometimes the right answer is not a rewrite.

That's an important distinction when you're working on production software.

Building business software is different from building a demo

A demo can work perfectly with three records.

Production software has to deal with reality.

Users make unexpected decisions.

Data is messy.

Imports are imperfect.

Multiple people can modify the same information.

Servers have limited resources.

Requirements change.

And suddenly a feature that looked simple on paper becomes an engineering problem.

I've worked on production business software involving financial analysis, document generation, confidential information, controlled sharing, spreadsheet and PDF processing, imports, exports, and complex business workflows.

The interesting engineering wasn't simply choosing a framework.

It was making the system reliable when things stopped being simple.

A real example: improving an existing business system

One production platform I worked on combined financial analysis, document drafting, sharing, exports, and deal workflows.

It had been built for real business use and continued evolving for years.

That meant dealing with things such as:

Legacy imports
Shared document state
Permission-aware workflows
PDF generation
Spreadsheet processing
Print-ready documents
Performance constraints
Database access
Production deployment
Ongoing maintenance

At one point, limited server resources exposed performance problems that weren't obvious from looking at individual features.

The solution wasn't simply:

“Buy a bigger server.”

The system needed to be understood as a whole.

Application behavior, concurrency, data access, architecture, and infrastructure all mattered.

That's the kind of problem I like working on.

I also build automation

Another area I focus on is business process automation.

A surprising amount of business work still looks like this:

Spreadsheet → copy/paste → email → another spreadsheet → manual verification → repeat

That is a good candidate for automation.

For example, I built InvoiceFlow, a Python toolkit that converts PDF invoices into structured invoice data and clean Excel workbooks.

The workflow is straightforward:

PDF invoices → extraction → structured data → Excel

But reliable automation requires more than making the happy path work.

You need validation.

You need error handling.

You need logging.

You need to think about larger workloads.

You need predictable output.

And you need a system that another developer can understand six months later.

That's why I think good automation is less about “using Python” and more about turning a messy manual process into a repeatable system people can trust.

My approach to software projects

My process is deliberately simple:

Discuss → Challenge → Plan → Build → Deploy → Maintain

First, I understand the business problem.

Then I challenge assumptions where necessary.

Then we agree on the architecture, workflow, scope, and tradeoffs.

Then I build.

After that, I deploy the system and remain available for improvements and maintenance.

I prefer this approach because software decisions compound.

A shortcut that saves two hours today can create weeks of maintenance six months later.

Likewise, spending time understanding the problem before coding can prevent an entire feature from being built in the wrong direction.

Why work with me?

I'm not trying to position myself as someone who knows every new framework.

My value is elsewhere.

I can take a business problem, break it down, understand the technical constraints, and turn it into software that can actually be used.

I can work on a new application.

I can join an existing codebase.

I can investigate a performance problem.

I can automate a repetitive workflow.

I can help modernize software that has become difficult to maintain.

And I can stay involved after the initial build.

Most importantly, you work directly with me.

No unnecessary layers between the business problem and the engineer doing the work.

Looking for a freelance software engineer?

I'm Ayman Atif, a freelance .NET and Python software engineer available for remote work worldwide.

If your business has:

a manual process that should be automated,
an application that has become difficult to maintain,
a slow backend,
a business idea that needs a technical plan,
or software that needs to be built from scratch,

I'd be happy to discuss it.

You can see my projects, services, engineering approach, and production experience here:

👉 Ayman Atif — Freelance .NET & Python Software Engineer

If you have a software problem that you've been putting off because it looks complicated, let's talk about it.

— Ayman Atif

I Built a $1,500 Dashboard. I Learned a Lesson Worth More Than $1,500.

Ayman Atif — Mon, 07 Sep 2026 14:12:54 +0000

Three months.

One client.

A complete agency dashboard.

And $200 paid out of an agreed $1,500.

I didn't lose those three months because the project was technically difficult.

I lost them because I approached freelancing like a developer instead of a business owner.

There was no signed contract.

There was no clearly documented payment schedule.

And when the project was finished, I didn't push for the remaining balance.

I simply moved on.

A year later, I still haven't received it.

Surprisingly, I'm not writing this article because I'm angry about it.

I'm writing it because the experience changed how I approach freelance web development.

The Project

The client ran an agency and wanted an internal dashboard to make some of their day-to-day work easier to manage.

The project involved several areas of their business.

There was client management.

There was blog management.

There was work related to SEO.

And there was the usual collection of smaller workflows that appear once you start building software around an actual business.

We agreed on a price of $1,500.

I received $200 upfront.

Then I started building.

From a development perspective, this was the kind of project I enjoyed.

It wasn't just a landing page or a simple CRUD application.

The software had to reflect how the agency actually worked.

That meant understanding their workflow, translating it into features, building the dashboard, adjusting things along the way, and making the application useful for the people who would actually use it.

So I kept going.

And I kept improving it.

For roughly three months, I worked on the project.

Eventually, the work was finished.

The application existed.

The features were there.

The client had what we had discussed.

But there was still one problem.

The remaining $1,300 never arrived.

I Was Too Easygoing About It

This is the part where I could simply blame the client.

But that wouldn't tell the whole story.

The client was responsible for paying the agreed amount.

I was also responsible for how I handled the business side of the project.

I didn't sign a contract.

I didn't establish a formal payment schedule.

I didn't clearly define what would happen if payment was delayed.

And perhaps most importantly, I didn't make payment a condition of continuing the work.

I was focused on building the software.

I thought:

"Let's get the project done."

That mindset is useful when you're trying to be a reliable developer.

It's not enough when you're running a freelance business.

Being easy to work with is good.

Being so easygoing that important business details become vague is not.

That's a distinction I didn't fully understand at the time.

The Developer Mindset vs. The Business Mindset

As developers, we're trained to think in terms of problems.

A client has a problem.

We come up with a solution.

We build it.

We test it.

We fix bugs.

We deliver it.

That's the part we naturally focus on.

But freelance development has another layer.

There is scope.

There are milestones.

There are payments.

There are approvals.

There are deadlines.

There are responsibilities on both sides.

None of these have much to do with whether you can write good code.

But they can determine whether a freelance project is actually successful.

That was the counterintuitive part for me.

I used to think that being professional mostly meant doing excellent work and being dependable.

It does.

But professionalism also means making expectations clear.

I Didn't Need a Complicated System

Looking back, I didn't need some sophisticated legal or financial system.

I needed basic structure.

Before starting the project, I should have had a written agreement covering things like:

What exactly I was building
What was outside the scope
The total project price
The payment schedule
What the upfront payment covered
When the remaining balance was due
How additional work would be handled
What happened if the project was paused

None of this has to make a client relationship cold or transactional.

In fact, I think the opposite is true.

Clear expectations make collaboration easier.

When both sides know what they agreed to, there's less room for confusion later.

The $200 Changed How I Look at Upfront Payments

The $200 upfront payment was important for another reason.

It showed that the client was willing to invest in the project.

But it wasn't enough to protect me from continuing too far without another payment milestone.

If I were handling the same project today, I would structure the payments around the work.

For example:

Initial payment → project begins

Milestone payment → major functionality completed

Final payment → final delivery

The exact percentages aren't the important part.

The principle is.

Don't let the entire financial risk sit on one side of the relationship.

I Also Learned Not to Confuse Kindness With Avoiding Difficult Conversations

This was probably the hardest lesson.

I didn't confront the situation.

Not because I thought the remaining payment was unimportant.

I just didn't want to create conflict.

So I stayed quiet.

Eventually, enough time passed that I stopped thinking about it.

A year later, the project is simply something I remember as an expensive lesson.

And honestly, I'm okay with that.

I would rather take the lesson than keep resentment over the money.

But if I could go back, I would handle the conversation differently.

Being respectful doesn't mean avoiding uncomfortable conversations.

You can be polite and still be assertive.

You can value the relationship and still set a boundary.

You can be flexible without making the agreement one-sided.

That's something I understand much better now.

The Project Still Taught Me Something Technically

It's easy to focus on the unpaid balance and forget the actual development experience.

But the project itself was valuable.

I got to work closely with an agency and build software around its internal workflow.

I worked on client management.

I worked on content and blog-related functionality.

I was involved in SEO-related work.

And I learned more about how businesses actually use software than I would have from another isolated personal project.

That's one reason I don't consider those three months completely wasted.

The money was never recovered.

The experience was.

And I still use what I learned from it.

What I'd Do Differently Today

If I started the same project today, my approach would be different.

I'd still listen carefully to the client.

I'd still try to understand the business before writing the first feature.

I'd still go out of my way to make the software useful.

But I'd also make the business side explicit from the beginning.

I'd document the scope.

I'd agree on milestones.

I'd use written communication for important decisions.

I'd make payment expectations clear.

And I'd stop treating conversations about money as something separate from professionalism.

Because they're not.

If you're providing a professional service, getting paid is part of the project.

The Lesson Was Worth More Than $1,500

I didn't get the remaining $1,300.

I can't go back and change that.

But I can make sure I don't repeat the same mistake.

The biggest lesson wasn't "don't trust clients."

It wasn't "always expect people to avoid paying."

And it definitely wasn't "be difficult to work with."

It was much simpler:

Good relationships need clear expectations.

A good client relationship isn't built by one person constantly being flexible.

It works when both sides understand their responsibilities and respect them.

That's reciprocity.

And that's something I wish I'd understood earlier.

Today, when I build software for a client, I think about more than whether the feature works.

I think about whether the scope is clear.

Whether expectations are documented.

Whether both sides know what happens next.

And whether I'm taking care of my responsibilities as both a developer and a business owner.

Because becoming a better freelance developer isn't only about writing better code.

Sometimes, it's about learning when to stop coding, have the conversation, and protect the work you've already done.

That lesson cost me $1,300.

I think it was worth learning.

> I'm Ayman Atif, a backend engineer and full-stack developer building production-ready web apps and tools. You can explore my work and latest projects at ayman-atif.vercel.app.

The Feature Worked. Then the Business Grew.

Ayman Atif — Fri, 04 Sep 2026 12:35:45 +0000

I’m Ayman Atif, a freelance software engineer focused on business software, backend systems, automation, and applications that have to survive real-world use.

A lot of my work starts with a deceptively simple sentence:

“The application works, but something is becoming a problem.”

Sometimes it is performance.

Sometimes it is a workflow that still depends on spreadsheets.

Sometimes a codebase has become difficult to change without breaking something else.

And sometimes the application works perfectly well in development, but production tells a different story.

One of the most interesting examples I’ve worked on started with something that didn’t look like a performance problem at all.

It was a business application.

The users needed to work with a lot of data, switch between different sections quickly, edit records, generate documents, process financial information, and keep several parts of their workflow open at the same time.

The application worked.

Until it didn’t feel fast anymore.

The deceptive phase of a successful application

There is a counterintuitive stage in software development where an application becomes a victim of its own success.

At the beginning, everything looks reasonable.

A database contains a few hundred records.

Pages load quickly.

Queries finish almost immediately.

The server has plenty of room.

Developers make decisions based on what exists today.

Then the business grows.

A few hundred records become thousands.

Users spend more time inside the application.

More tabs are opened.

The requirement that made everything harder

One requirement in particular made the problem interesting.

The users wanted the application to behave more like a desktop application.

They didn't want to constantly navigate between pages.

They wanted to open different sections, switch between them, keep their context, and work with large datasets directly inside grids.

And in some areas, they wanted thousands of records visible without traditional pagination.

From a user's perspective, that makes perfect sense.

If you're working with financial or business data all day, constantly clicking through pages can become friction.

You want to search, sort, inspect, edit, and move on.

But every convenient interaction has a cost somewhere else.

The browser has work to do.

The server has work to do.

The database has work to do.

And memory has to go somewhere.

The more desktop-like the web application becomes, the more important it is to understand what is actually happening underneath the interface.

I stopped looking at the page

The first instinct when a page becomes slow is often to look at the page.

Maybe the JavaScript is inefficient.

Maybe the rendering is expensive.

Maybe the browser is struggling.

Those things can certainly happen.

But I learned to resist fixing the first thing that looks suspicious.

Instead, I started following the entire path.

Database.

↓

Backend.

↓

Serialization.

↓

Network.

↓

Browser.

↓

DOM.

↓

User interaction.

That sounds obvious, but it changes how you investigate a performance problem.

If you only look at the frontend, you can spend hours optimizing something that represents a small percentage of the actual problem.

The same is true in reverse.

A database query might be fast in isolation while the application still feels slow because too much data is being transferred, processed, or rendered afterward.

Performance is a chain.

The user experiences the slowest part of that chain.

The server has a vote too

There was another constraint that made the problem more interesting: the server wasn't unlimited.

The application had to operate within a relatively small amount of memory.

That changes how you think about architecture.

You can't simply throw more infrastructure at every problem.

Sometimes the right answer is optimization.

Sometimes it is changing when data is loaded.

Sometimes it is reducing unnecessary work.

Sometimes it is processing things differently.

And sometimes you have to question the original design.

This is where I think business software differs from many toy projects and tutorials.

In a tutorial, you can say:

“Let's add another server.”

In production, someone has to pay for it.

And even if you can afford it, more infrastructure doesn't automatically fix inefficient data access or excessive memory usage.

You still need to understand the system.

Then there was shared state

Performance wasn't the only problem.

Once multiple people are working with the same information, another category of problems appears.

Who owns this change?

What happens if two users edit the same thing?

Which version should win?

When should state be saved?

What happens if the browser closes halfway through an operation?

What happens if a user opens several sections and modifies information in one while another section still contains an older representation?

These aren't UI questions anymore.

They're system-design questions.

A business application is full of shared state.

That means reliability depends on more than making individual functions work correctly.

You have to think about the relationships between those functions.

The lesson I took from it

The biggest lesson wasn't a particular optimization technique.

It was a change in how I think about software.

A feature doesn't exist in isolation.

It exists inside a business.

The business grows.

The data grows.

Users change their behavior.

Requirements evolve.

Infrastructure has limits.

And eventually, assumptions that looked completely reasonable during development are challenged by reality.

That's why I prefer investigating a system before proposing a rewrite.

When something becomes slow, fragile, or difficult to maintain, the answer isn't automatically “replace it.”

First, understand it.

Find where the real constraint is.

Measure what is actually happening.

Then change the smallest thing that meaningfully improves the situation.

Sometimes that leads to a refactor.

Sometimes it leads to a database change.

Sometimes it requires changing how data moves through the application.

Sometimes the architecture itself needs to evolve.

But you should know why you're making the change.

Software gets interesting when it meets reality

I've been building software since 2014, and most of the lessons that stayed with me didn't come from writing the first version of an application.

They came afterward.

When users started depending on it.

When the database became larger.

When a server had less memory than expected.

When two people changed the same data.

When a feature that looked simple turned out to affect five different parts of the system.

That's the point where software engineering becomes less about making something work and more about making something people can continue to rely on.

That's also the kind of work I enjoy most.

I build and improve business applications, backend systems, automation workflows, APIs, and existing software that has reached the point where it needs careful engineering rather than another quick patch.

If you're dealing with a business process that has outgrown spreadsheets, an application that has become difficult to maintain, or software that needs to become more reliable as it grows, you can find my work and get in touch with me at ayman-atif.vercel.app.

The goal isn't just to write software.

It's to build something the business can actually rely on.

DEV Community: Ayman Atif

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

3. var Is Not dynamic

4. ref, out, and in

5. LINQ: When Does This Code Actually Run?

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

7. IDisposable and using

8. Dependency Injection Lifetimes

9. Entity Framework Core Tracking

10. Exceptions: Catching Everything Isn't Defensive Programming

11. Collections Are Part of Your Design

12. static Deserves More Thought Than It Gets

13. Equality Is More Complicated Than ==

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

The Pattern I Keep Seeing

You Don't Outgrow the Fundamentals

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

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

The Business Problem Comes Before the Technology

Production Changes Your Definition of "Working"

Performance Problems Are Often System Problems

Existing Software Deserves Investigation Before a Rewrite

Automation Is Mostly About Understanding Repetition

Maintainability Becomes Very Real When You Maintain Your Own Code

Simple Software Is Usually Hard to Build

Communication Is an Engineering Skill

The Best Technical Decision Depends on the Business

What I Care About After 10+ Years

I Was a .NET Developer. Then My Company Told Me to Learn Android.

Java got me into Android development. Kotlin made me stay. Years later, I still build Android apps for fun.

Going from C# to Java

Android felt different

Then Kotlin showed up

Jetpack Compose changed the experience again

My latest Android side project

The PDF part became the interesting problem

I also wanted two very different resume styles

The app became something I wanted to release

Why I still build Android apps

About me

Ayman Atif: How I Build Software Around Business Problems

What I do as a freelance software engineer

I start with the business problem

Building business software is different from building a demo

A real example: improving an existing business system

I also build automation

My approach to software projects

Why work with me?

Looking for a freelance software engineer?

I Built a $1,500 Dashboard. I Learned a Lesson Worth More Than $1,500.

The Project

I Was Too Easygoing About It

The Developer Mindset vs. The Business Mindset

I Didn't Need a Complicated System

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 `==`