How We Build Elegant Software From Scratch Within A month?

Can you build an elegant software program in 30 days? TigerTeamX.com has successfully achieved this feat. How so, you might ask? Our development process is built on character and determination.

One of our software tools launched is ElegantDoc.com. It is a document design tool that allows users to create aesthetically pleasing documents at a fraction of the time of other services. Furthermore, it is affordable, easy to use, and saves time for businesses and individuals.

As a team, we’ve made a New Year resolution for 2023, which is to make quality software. Elegantdoc.com is just one example of how you can elegantly build software from scratch in a month. Achieving this goal requires you to be particular about many things.

Minimize to the bare bones

You need to be a minimalist to be simple. The two go hand in hand. It's about maintaining elegance and efficiency without the 'shiny object syndrome.' As Leonardo da Vinci once said, "Simplicity is the ultimate sophistication."

As a developer, you want to avoid over-engineering to prevent bloat and unwanted abstractions.

Minimizing to the bare bones is not writing fewer lines of code but coding what matters. Developing software from scratch means thinking about 'must have' rather than 'good to have' features.

It's about creating something that gets the job done for your users with the least number of programming languages, tools, database systems, and lines of code.

For instance, we already have a minimum viable product with about two weeks of development hours with ElegantDoc.com. This service helps users create elegant documents in seconds. We simplified the editor to work on the desktop version without a fancy drag/drop editor. We began with four templates instead of the 20 we had in mind.

In the case of ElegantDoc.com, we only had a few templates initially. However, we had enough for a minimum viable product. Even ElegantDoc.com's website is pretty simplistic but has clear navigation and showcases what the service does.

Another example is Duckist.com, which is also minimal in the website and product design. It has one crucial page for people to use their service of encrypting messages or files.

Sketch first

We utilize rough paper sketches, which are faster than systems like Miro and Draw.io. As a result, you have more creative freedom and reduce clutter, which is both in keeping with simplifying things.

Less is more. Some questions we ask ourselves include the following:

1. How can we get rid of as many windows as possible?

2. Can the user setting be so simple that they'll require nothing, if not very little?

3. Rather than having a “new” page, you can create a modal. It helps you to build faster and makes it simpler for users to learn your system, increasing their retention. We have two sketches of ElegantDoc.com below to explain these concepts.

Although they are not the first drafts, they showcase the idea of moving fast. ElegantDoc.com has evolved ever since. Yet, you can see that we didn't have a login/signup feature in our sketch.

In our task description, we stated to copy the design of Protonmail for login and use something similar for signup. So, while Protonmail differs from our startup, we liked their design.

This is essentially our requirements specs as part of our plan.

Insert images from the document file

Of course, we can represent this with fancy interactive 2-D or 3-D techniques. However, when you plan to build software in a month, a low-fidelity spartan approach is more straightforward. Here, we mean paper sketches, usually in diagram form.

Your sketch can cover the following necessary elements when you plan to develop software:

Context Diagram

Here, you map out the relationship between the system and the surrounding environment of affected parties, e.g., customers, suppliers, managers, etc.

Use case

This element aims to represent how different users will interact with the software and their benefits.

Activity

Activity considers what the different users will be doing at the steps of the use case model. In essence, it is a flowchart of actions.

teal design

Steal from others. When you create any solution, it's natural to observe what others have already produced, identifying any weaknesses that need improving. For instance, you can look at designs from Airbnb if you want to make a real estate site.

At the same time, it's about making it better and unique. Making it yours. So with a real estate site, you can change the colors, padding, etc., to create your brand.

The whole idea is about tweaking. Some developers may consider hiring a designer for a custom design. It can take weeks for a design even if you find someone, not to mention the high labor cost. Remember, we are here to save time and money.

Test critical assumptions first, omit everything else

For any software building plan, you'll want to test critical assumptions first; keep what's working and omit what isn't. With ElegantDoc, we first tested to see if we could create a nice and easy PDF with Python.

Rather than building the MVP first, we made a small command line script for building the PDF. If it were not possible to create beautiful PDFs easily, that would mean we should make our PDF rendering engine.

That would make this project too time-consuming, and thus we could scrap it before wasting too many resources.

Note that this concept applies not only to fast startups like this but to other companies too. So test your critical assumptions first.

Besides this, we do code reviews even though it is time-consuming. It helps to have another pair of eyes when you develop software to evaluate potential defects, improve your code's quality, and transfer new knowledge. It helps simplify solutions before the solution gets over-engineered.

We also have a manual tester assessing things as we move along. While not the most efficient method, good testers aren't pricey. With a small product, they work fine, and it only takes a few hours to go through all the functionality.

Don't hire too many people

The late, legendary American computer scientist Fred Brooks once said, "Adding manpower to a late software project makes it later."

A month to build elegant software is, of course, late for many people. This is where Brooks' law comes into play. This means the approach to hiring software developers needs to be effective. How? By choosing small but experienced teams.

For many of our projects at the early stage, we have a single front-ender and a single back-ender. We also have a single team leader who contributes to the programming and tests everything. Since all our focus is on development, we have a fantastic team of writers at Twiyo Content to help market the software. They are their tiger team in marketing.

There are several reasons why having a small team is beneficial:

Easier collaboration

Working in the same office or remote setting is easier with a small group of developers, allowing for simpler communication. This collaboration also fosters closer relationships because you can get to know your teammates better.

Increased learning

You can turn the fact of having limited resources into a positive. Each team member must be responsible for more different software features than usual. It increases problem-solving abilities.

More business-level involvement

The software build process goes beyond engineering. We must consider customer support, sales, marketing, and the list goes on. Within a massive corporation, you are a small part of a large operation with fewer responsibilities.

It is easier to see the bigger picture within a small team.

Set clear requirements and roadmap

You should follow a logical sequence of steps when you build software applications. This is why a roadmap is essential to plan every process stage. These are guidelines that all team members should know before they start working.

They will precisely know what needs to be done and when, saving much time on the project.

The roadmap first defines the software's vision and the 'why' for the product's existence. Secondly, your team will create the long-term blueprint of the goals and themes. Finally, it completes actionable tasks with deliverables during this time.

Define best practices

When moving fast and for maintainability we found benefits focusing on

• KISS (Keep It Simple, Stupid)
• YAGNI (You Ain't Gonna Need It)
• Make your code readable

In other words, avoid any extra engineering. Solve, for now, don’t think later.

And avoid these

• Excessive refactoring
• DRY (Don't Repeat Yourself)
• Focus on your technical debt
• CI/CD

These are often overused and not useful when you’re doing smaller work. CI/CD becomes more important, but DRY is one of the most overused patterns out there. I’ll soon make a blog article about why you should avoid DRY.

Try different ideas to create a good logo

You should have all the steps to create a software program at this point. The logo design is the easiest step and is something you don’t need to worry excessively about, especially at the beginning.

Our rule of thumb is that you don't need to break the bank here. The expensive route isn't necessarily the best when cheaper options are available to get the job done.

You can use sites like https://freeimagegenerator.com/ and https://www.alamy.com/ to build ideas. Be as minimalistic as possible; that has been the trend for any business. Stripped-down logos are more memorable, consistent, and adaptable across different platforms.

Next up, you can visit freelancing platforms like Fiverr, where you will surely find someone to design your logo at an affordable price.

Deploy simple

Low-code and no-code solutions have become increasingly common for developers to build software. It's certainly great if it's possible for your project. However, when it comes to deployment again you should keep it simple. You won't need to be web-scalable as you won't have a lot of users. It’s great if you get that problem! Now you know what to focus on. Keep it simple. We use Caddyserver (an alternative to NGINX) and run it on a VPS (Virtual Private server). It’s simple, cheap, and it works. If you’re familiar with Heroku, do that. Avoid using fancy stuff like Kubernetes. It won't give you anything.

Use simple databases

There’s no need to use a full-blown SQL server. SQLite3 is sufficient. It is easy to set up and enables simple backups. The second straightforward option is choosing a directory with JSON files. It sounds crazy, but it is often good enough.

Configuration

Keep it simple with just a config file - no need to use a specialized system or anything else.

Staging environment

A simple setup system results in a relatively easy staging environment, which we believe is worth it. This method allows for a 'finished' system, where a tester can test everything before going live.

No automated testing happens at this stage since we move fast. We don't write unit tests as they would break the following week. Adding unit tests or continuous unit testing makes more sense after going live, and when you have new features.

Why would you do it in a month?

We have reached the final part of learning to build great software in only 30 days. Why would you do it in such a short period? After all, good rarely comes from rushing things.

The goal is to create a minimum viable product as early as possible, which can be improved later based on user feedback. It doesn't need to be perfect, but it should have enough functionality for user feedback.

This is the agile approach to software engineering, which is different from the traditional waterfall approach. It is more linear and aims for a complete product after the project is done.

On the other hand, agile is about being swift and flexible, delivering the product in increments. You break down tasks into smaller planned iterations, lasting 1 to 4 weeks. Long-term planning is not the objective despite the software's vision being laid out beforehand. This is one way that you can create software faster and at a cheaper cost.

Building elegant software in a month requires much experience and planning, but you can deliver a scaled-down version. We believe it's the best method for testing out a product. Don’t you agree? Check out How We Do Software to learn our exceptional process of developing world-class software.