Designing a Custom System pt. 2

Read 636 times 11 Feb 2014
Written by 

This is part of our informational series on custom software development and web design. These are designed to inform the public at large about the process of software development. As such, these are written in plain-English without a lot of technical jargon.



Scope of Work

In our last blog on custom software and web development, we discussed some of the general parameters of development. Today we're going to focus on the nuts and bolts of developing a solution. We'll discuss how to estimate the cost and scope, why it's important to have a detailed production plan, and some good management tools to use. We'll also discuss milestones in terms of their importance, and we'll touch on a little of Agile Development. Of course, anything that is done right is thoroughly tested, and we'll also talk about considerations you'll need to have in order to launch your website or software system.

First of all, you need to know the entirety of the project you will be working on. That requires a Scope of Work (SOW) submitted by the client (you) before your developer starts. This is a tricky piece, since the you many not often do not know the details of your requested systems. Not everyone is tech-savvy enough to break down the scope into the appropriate steps. This becomes an issue when we are talking about general statements such as “user logs in,” for example. What may not be clear is that you want different permission levels, and desires some behavior on the user by the type of user. (For instance, user class #1 sees one type of content, user class #2 sees another). This may not be clear when give designers the SOW. Only a qualified and experienced developer can sniff out those discrepancies between what’s written and what’s expected.

Scope of Work documents do a few things. They allow the developer to accurately quote the work, and the allow the client (you) reasonable expectation of results based on what’s been bid. The devil is in the details. Technically, that’s up to the client to come up with the scope, not the developers. Some firms will assist you in preparing an accurate scope of work, as we do here at Tucknologies. It’s important for both sides to know exactly what needs to be done.


However, there are instances where you want to have software to complete a goal or to support a concept. That is when you have to expect that there will be decisions made about how to accomplish those goals that are made by the firm you hire. Some clients like this approach, and it does offer the development firm a little more flexibility. There is always “more than one way to skin a cat.” 

So determining exactly what needs to be done is paramount to start. One can’t even have a complete bid until the software developer knows what they will be building. 


Detailed Production Plan

Once the scope has been determined, and both parties agree, then the firm should put together some kind of detailed production plan. This is accomplished a number of different ways. At Tucknologies, we approach it with a creative-first approach. It’s not the only way, but it’s the best way we’ve found to operate. 

Because all of us lead with our eyes, and we know what we like when we see it; that makes for the rest of the development dependent on the creative. So, we conduct a creative audit. In the creative audit, we determine all of the collateral material that the client has: Past marketing campaigns, logos, style sheets, brand standards, copy, and any other creative work, etc. Then we determine what creative is missing and set a plan to acquire those things or creative them. Out of this, we’re able to set a schedule, determine the style and look, and start working on the mock-ups and information architecture.

Next, we determine the Information Architecture (IA). What that is, quite simply, is the art and science of organizing and labeling data including: websites, intranets, online communities, software, books and other mediums of information, to develop usability and structural aesthetics. That includes how the server will operate, what protocols the website or software will use, and how the database is structured. This can also include R&D into 3rd party features such as plugins and purchased software components to build the requested software. As you can imagine, this requires specific knowledge and experience in order to get it right. Architecture is a very appropriate word here, as this is akin to an architect building plans for your residence. You don’t want some person that hasn’t done it before!

Then content gets developed. This is where the coding takes place, and leads us to the next topic we’ll be discussing today: 


Management Systems

Content gets produced, and if you are a full-service firm like Tucknologies you have specialists working on each piece. For instance, we have a team of graphic designers and they will work on the artwork as the engineers and programmers work on the code. This requires a management system, unless your developer is a one-man-band who works out of his momma’s basement.

Some developers do it Ad-Hoc, creating a management system as you go. This works with small teams at boutique firms, who are all in one place. For full-service firms, who have multiple employees each working on a different piece (sometimes in different locations, at different times) this won’t work. Each time a programmer downloads a piece of code to work on, and uploads it back to the server, it will overwrite everything that was there before. What if more than one person is working on it at a time? Suddenly, an ill-advised update of the server will wipe out all of another team member’s work. Ouch. Nothing like having to pay for it twice!

We use project management software. Some of the most popular web-based ones, that we have or are using are Basecamp, Apollo, Asana, and to name a few. We aren’t going to break down the features or compare the project management software here, but we do have a link for you to check out that is done for you. We prefer to use the online PM software because we can access it at any time we have a connection. There have been times when being able to check a project’s status via mobile phone has been life-saving. We have used other types of systems, but these are the best for what we do. Some of the great things about using these are that all of the project’s materials and resources are brought to one place.



You like to know what your developer is doing, and see progress right? Of course you do. That’s where milestones come into play. A good developer will have an idea of what will be done by when; meaning they will be able to provide you with a reasonable time frame for each step in the process. Milestones give both sides an important way to measure the effectiveness of the development. As a client, you probably want it tied to pieces. As a developer, they will want it tied to time. At Tucknologies, we do a hybrid of both. There is an expectation of pieces/time period and we recommend any client or developer to adopt this position. A developer can’t work without compensation, and the client shouldn’t pay without results. Both can be attained, if the software and web developer is experienced.



Testing is probably one of the most important components of developing any type of technology. It has to work, and that’s what the firm you hire should care the most about. There are two ways to test: One can build the entire thing and test it, or a firm can build each piece and test it. The problem with building the whole thing is that you can’t test the system until it’s done, meaning if there are issues it takes a lot of effort to re-do pieces that have already been built. For obvious reasons, this is a type of testing that doesn’t work with large systems. Small pieces, such as a contact form, or payment processor may not need to be developed using Agile Development. Large systems like e-commerce and database integration make it necessary to test as you go.

Agile Development, for the layman is a way in which developers ensure quality. Each piece is broken down into “sprints” which get assigned a time, resources, and other inputs necessary for it to be produced. Then, as the piece is produced it is rigorously tested to make sure that it works, before the team(s) move onto another piece of the puzzle. It has been adopted by most firms, and is especially relevant for custom development. However, there are some instances (like a template based website, complete with frameworks and plugins) where Agile makes less sense. These however, are the exception and not the rule.

It’s not just testing the expected user experience. If you are building a shopping cart, a software development firm will make sure that the quantities and totals add up, and that it shows and processes the right product. That’s the expected result. But at Tucknologies we also test what is NOT expected to happen. What happens if the user enters in a negative number? Does that mean that the company now owes the consumer? What about a request of a million items? These are unexpected results and have to be tested thoroughly under any condition.



Once your firm has finished the testing, and the product is ready to go you are getting close to launch. This is when the marketing department takes over in the product lifecycle and begins to promote and advertise the product. If your custom system was made from the beginning with marketing the product in mind, then this period is relatively smooth. If not, then there is a mad rush and a gnashing of teeth on both the engineering and the marketing departments. 

As you can probably guess, it’s best to build with marketing in mind. Marketing will inform you as to what your customers want, how they interacted with you in the past, and what goals the system is trying to accomplish. These things need to get built into the software or website or mobile app. For instance, if none of your customers care about a feature that the new system has, why should it have been built in the first place? Perhaps the target market needs fonts that are clearer or larger. These considerations need to be part of the development process, and some development firms don’t have the experience to do these things. That is a consideration you want to make, well before you launch!


Who We Are


« September 2017 »
Mon Tue Wed Thu Fri Sat Sun
        1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30