One thing I like about software development is that there isn't one way to write code.

Writing complex architecture, scaling an app, or formatting clean code are all possibilities, depending on the project's technical challenge.

I am a completely different developer between collaboration with clients and solo projects.

On one side, it involves implementation thinking, integration into existing code, and clean formatting with unit tests. On the other hand, it is purely feature-oriented, neglecting quality.

At first, it may seem counterproductive, but here's why it may not:

Speed Up Architecture

Developing for a company puts you in a scaling environment, and you are not alone in working on the project. For those reasons, writing clean, scalable code is essential to persist.

But solo development is entirely different. When I develop a new app, I do not think about fancy architecture or clean coding. I know what I am writing.

But it all depends on the level of ugliness you want the code to be. For example, here is an architecture for an app during the one app/week challenge:

And here is the one for Swift Maker, which provides a minimal code organization to scale your idea:

Swift Maker has a cleaner and scalable architecture by decoupling part of your app with modularization.

However, one downside of complexifying an architecture is that you must follow its constraints when writing code. Let's be honest, this takes more time than writing simple, to-the-point code like the first image.

If you want to try your app idea, you shouldn't worry about the code or implementation but the value users will perceive.

Let's get deeper. We can define which code impacts the user (like a new screen or feature) and which is just for our sake (file organization, better architecture, smaller views). Each line of code has a valuable impact on the users. How is your code helpful for them?

Ugly code doesn't mean ugly features. On the user's side, it should work perfectly to provide value.

If you are a developer writing clean code, I challenge you to write ugly for a personal project. At first, it may be frustrating, but you will be faster.

Forget ViewModel

Most SwiftUI apps are developed with ViewModels. But it seems that Apple is pushing to directly use properties inside Views as we don't need to care about the data source binding (especially for SwiftData).

Instead of writing ViewModels, you can gain time by writing directly the properties in the View. One file, straightforward, no back and forth. Simple but effective.

Forget Unit Testing

Does unit testing provide something for the user? Feature stability, maybe, but is it worth the time spent and the code organization?

Personally, I prefer to test the idea with the market, to answer that question, are people willing to pay for it?

When I get some answers to that question with a solid user base, we may bring unit testing to the table, not before.

So here are the main things to keep in mind to develop faster for your solo projects:

• Write straight code
• Don't use ViewModel, but properties inside Views
• Don't write unit tests at the beginning

What strategies are you using to write code effectively? Let me know in the comments 👇

Take care & see you next week.