Question: Recently, I read a lot of good articles about how to do good encapsulation. And when I say "good encapsulation", I am not talking about hiding private fields with public properties; I am talking about preventing users of your API from doing wrong things.

Here are two good articles about this subject:

<http://blog.ploeh.dk/2011/05/24/PokayokeDesignFromSmellToFragrance.aspx>

<http://lostechies.com/derickbailey/2011/03/28/encapsulation-youre-doing-it-wrong/>

At my job, the majority of our applications are not destined for other programmers but rather for the customers.

About 80% of the application code is at the top of the structure (Not used by other code). For this reason, there is probably no chance ever that this code will be used by other application. 

An example of encapsulation that prevents users from doing wrong things with your API is returning an IEnumerable instead of IList when you don't want to give the ability to the user to add or remove items in the list.

My question is: When can encapsulation be considered simply OOP purism, keeping in mind that each hour of programming is charged to the customer?

I want to create code that is maintainable and easy to read and use, but when I am not building a public API (to be used by other programmers), where can we draw the line between perfect code and not so perfect code?

Answer: 
Answer: When you have your interface complete, then automatically you are done with encapsulation. It does not matter if implemenation or consumption part is incomplete, you are done since interface is accepted as final.

**Proper development tools should reduce cost more than tools cost themself.**

You suggest that if encapsulation or whatever property is not relevant to market offer, if customer does not care then the property has no value. Correct. And customer cares nearly about no internal property of code.

So why this and other measurable properties of code exist ? Why deveoper should care ? I think the reason is money as well: any labor intensive and costly work in software development will call for a cure. Encapsulation is targeted not at the customer but at user of library. You saying you do not have external users, but for your own code you yourself are the user number 1. 

* If you introduce risk of errors into daily use, then you **increase the cost of development**.
* If you spend on reducing the risk, you will **increase the cost of development**.

Market and evolution keep forcing this choice. Choose the least increase.

This is all understood well. But you are asking about this particular feature. It is not the hardest one to maintain. It is definitely cost effective. But be aware about laws of human nature and economy. Tools have their own market. The labeled cost for some can be $0, but there is always hidden cost in terms of time spent on adoption. And this market is flooded with methodologies and practices with negative value.
Encapsulation exists to protect your class invariants. This is the primary measure for 'how much is enough'. Any way to break invariants breaks class semantics and is bad (tm).

A secondary concern is limiting visibility and as such the number of places that can/will access data and thus increase coupling and/or number of dependencies. This needs to be done with care though. As requirements change, often times that decision to limit what the class exposes leads to awkward hacks to deal with the new requirement.

This though is one of those design concerns that comes with experience. In doubt, favor encapsulation. The concerns are regardless of 'public' API or not. Even for internal code, new or forgetful or sleepy programmers *will* write bad code. If your class needs to be resistant to bad code, then do so.