Choosing Between SaaS and a Custom Website

2021-05-18T00:00:00+00:00

So you need a website, but you’re not sure whether you want to pay for a website provided as software as a service (SaaS), or build a custom website and host it.

The options are plentiful, as are the reasons for building a website in the first place. The purpose of this article is not to put forward specific packages or providers for consideration, rather I want to discuss how you might make that decision more objectively. Also, this discussion is for a commercial website, not a personal website or blog.

Here at End Point, we receive many inquiries asking for new websites. We are well equipped to help you work through this process, and are happy to do so. But for those of you who want to “go it alone”, or if you just want to be better prepared before giving us a call, read on for some things to consider as you make a pros & cons list for SaaS vs. custom websites.

While deciding between a SaaS offering and a custom build carries unlimited considerations, here are a few main points to help you narrow down the field.

Experience

The foremost factor that you should consider for your pros & cons list is your experience. This may come as a little bit of a shock, as you might think that budget would be the top consideration. Budget is very important, but it is largely determined by your experience with your chosen technology. Don’t think for a minute that either SaaS or custom development cannot consume almost any budget, especially when you are working with an unfamiliar technology.

So before budget, comes experience. Experience can be futher divided into experience with your business and experience with websites in general. Here are a few questions to start off with.

In your industry, are you a:

Rookie
Veteran

How long have you owned this business?

1–3 years
3+ years

Does this business have an existing website?

If yes, is it currently SaaS or custom-developed?

SaaS
Custom-developed

If you answered “1” to more than half of the above questions, it’s more likely that a SaaS system would be a better fit for you. If you mostly answered “2”, you may want to lean towards custom. These questions are not definitive, but are meant to help you decide where to focus your research.

Budget

In general, if your budget is under $10,000 then SaaS is most likely the choice for you. Some exceptions here:

You are a talented web programmer.
Your brother, sister, friend, or cousin is a talented web programmer.
You or your developer friend have enough time to devote to this endeavor. You will need a lot.

Custom websites are no longer appropriate for the average business owner with less than a $10k minimum start up cost, as well as a $1–3k monthly budget for ongoing improvements and maintenance. Currently, droves of talented programmers are working for SaaS companies, building tools for you to use to build your own website. In fact, SaaS offerings are so much cheaper and more widely supported that building a custom site for the average small business usually makes little sense.

If your budget is $10k or more, you are probably capable of funding a custom website. However, this alone should not rule out a SaaS website. SaaS offerings come in many shapes and sizes, and many are fully capable of running enterprise-level websites!

How does your business make money?

One good case for using a custom website is if your company offers a niche product. Most SaaS offerings are based on popular business or product templates, so they might not fit well if you need to break from the mold.

For example, do you sell clothing, movies, or tools? There are great SaaS offerings out there that can have your website up and running in less than a day. Do you provide a service that uses multiple providers, working in different capacities and for different rates depending on the level of service provided? You may need a custom application! The further from commonplace your products or services are, the more likely it is that you will need a custom application.

Again, all of this advice is general, and there are exceptions to every rule. SaaS choices still require customizing to fit your business model. None of them will fit perfectly, and you will usually need to configure and add plugins to make your site conform to your business practices. SaaS offerings typically have a wide range of plugins and customizations to accommodate this. Those extras usually cost extra too.

While SaaS sites do provide a great starting point with a plethora of potential plugins, in many cases plugins are supplied by 3rd parties. That means that if you have problems with the plugin, you will need to deal with that provider separate from the main service provider.

A lot of time and money can be spent trying to make diverse systems work together. SaaS can be more “turn-key” in the beginning, but especially for more complex websites, it can end up costing more than if you created a custom site in the beginning.

What vendors does your company work with?

Vendors are sometimes overlooked when trying to decide on what type of website will be needed. Here are some questions which might complicate your website:

Do you use a 3rd party to ship or fulfill your products?
Do you sell your products on Amazon, Google Shopping, or other providers?
Do you use a vendor to provide your products to you?
Do you assemble the product after receiving parts from different vendors?
Does your company use any software for customer management, accounting, or shipping?

If your answer is yes to any of these questions, you need to know what platform each of those vendors or platforms use, and if it is compatible with the website you are planning to build. Almost all business done today involves the exchange of information between you, your customer, and your vendors.

That exchange of information usually takes place through an Application Programming Interface (API). If you aren’t familiar with APIs, here’s a great explanation. Understanding how websites communicate with your vendors is very important.

The point is that if you plan on doing any volume of business, at some point you will need to exchange information with some vendor or other. Verifying that your new website is capable of exchanging information with existing vendors is a big consideration for you to make before you build. Building a website without the required APIs would be like building a house without any provision for water, plumbing, or electricity. This is important stuff, and it can get very expensive to retrofit!

Is that all?

Absolutely not. There are endless considerations that can play into your decision. But hopefully this post has given you some good ideas of where to start and will help you avoid analysis paralysis. Use this information to get a good idea of your needs and document them, so that you can investigate the right things. Compare how well different solutions fit your needs.

Who knows, you may start with a SaaS solution for a few years, and then when things are rolling and you have a better handle on your site layout, migrate to a custom-built site. There are no set rules.

Don’t read an ad for a website service offering to find out you what you need in a website. Determine what you need in your website and look for a product which meets your needs!

Why upgrading software libraries is imperative

2020-06-10T00:00:00+00:00

Image by Tolu Olubode on Unsplash

Applications primarily run on front- and back-end programming languages, including library dependencies. Operating systems and programming languages can be periodically updated to run on the latest version, but what about the many libraries being used in the app’s front and backend? As we all know, it can be quite a daunting task to maintain and individually update a long list of software dependencies like the examples later in this post. Still, it is important to keep them updated.

This post dives into our experience upgrading a complex app with a full software stack and lots of dependencies. We’ll examine the benefits of upgrading, what you will need, and how to go about such an upgrade as simply as possible.

The app in question contained decade-old software and included extensive libraries when we received it from our client. The app used languages including Java, Scala, Kotlin, and JavaScript along with many libraries. The initial plan was to upgrade the complete software stack and libraries all at once due to the gap between versions. This proved to be more difficult than expected due to a host of deprecated and removed functionality as well as interdependence of a few of the libraries.

Conflict approach: “Don’t update unless you have to”

While this can be sustainable in the short term, it quickly becomes less applicable in the long run. One important purpose of updates is to (hopefully) protect from new vulnerabilities and cyber attacks. Scenarios arise where particular library fixes are implemented on the latest version, yet require upgrading other libraries to the latest version in a chain. Because upgraded libraries need extensive testing and preparation for new issues, this directly impacts whether the app attempts to resolve an issue.

Therefore, smaller and more frequent updates are more sustainable in the long run. Larger and less frequent upgrades will not only result in unexpected errors, but also require more complete regression testing to deliver a bug-free update. The following reasons justify the necessity of software and library upgrades:

They apply timely security patches to reduce vulnerabilities and defend from cyberattack
You can identify deprecated functionality earlier and use alternatives
They can apply fixes for known bugs in the library
They’re based on the latest versions of software or library, encouraging stability

In addition, staying on the latest major version yields the benefit of applying minor and patch releases seamlessly without risk. Most software and libraries use semantic versioning, formatted as MAJOR.MINOR.PATCH:

MAJOR version - Incompatible API changes
MINOR version - Add functionality with backward compatiblity
PATCH version - Bug fixes with backward compatibility

So being on the latest major versions of libraries allows applying minor and patch releases without breaking existing functionalities of the app.

Benefits

The benefits of keeping software and libraries updated include bug fixes, new features, boosted performance, as well as better stability, compatibility, and security measures. We can often ignore upgrades in projects because we don’t perceive significant effects in appearance or usage. But on closer inspection, frequent updates deliver important advantages.

Real-time difficulties

In real-life scenarios, bug fixes and performance optimization of an app often take a higher priority than upgrading libraries. In many cases, this results in a discrepancy between the app’s version and the current version. This discrepancy can lead to the following issues when upgrading libraries:

Unexpected error handling in new releases
Unexpected unsupported library dependencies
Need for complete end-to-end testing due to major version of library upgrade
Lack of work being visibly completed can lead to a lack of confidence from client
Difficulty in estimating workload due to major unexpected errors

The following passages offer guidance in how to adequately prepare for these issues.

Get prepared

Much can be learned from preparing for a major upgrade on both a business and technical level. First, a complete list of libraries from the entire app should be compiled. This list should include the latest and current version of the library in the app. Reviewing the changelog of both versions will help identify potential incompatibilities or problems. Visiting the “issue report page” of the library to monitor any version-specific issues is also recommended.

Once you’ve adequately prepared the libraries for upgrading, you can use any method of your choosing to upgrade and maintain the list. Once the roadmap is established, upgrading can commence and compatibility issues that arise can be dealt with as they arise. Finally, thorough end-to-end testing is necessary once the upgrade process is complete.

Below are some examples of software lists you might have for a project (we left out the latest versions for brevity in this post, but it’s helpful to have a column for those too!).

Programming software & servers

Software	Running	Release date
Ubuntu Linux	12.04.5	2017-04-28
nginx web server	1.12.2	2017-10-17
Jetty Java Servlet container	9.2.3	2014-09-05
JVM/Java	1.7u79	2015-04-14
Scala	2.11	2014-04-21
Kotlin	0.9.223	2014-10-23
Lucene	4.10.0	2014-09-03
PostgreSQL database	9.3.10	2015-10-08

Java libraries

Software	Running	Release date
joda-convert	1.3.1	2013-03-01
joda-time	2.2	2013-03-01
play-json	2.7.0	2019-01
httpclient	4.1.2	2011-07-10
httpcore	4.1.2	2011-07-22
httpmime	4.1.2	2011-07-29
commons-codec	1.3	2005-10-01
jooq	3.1.0	2013-06-30
jooq-codegen	3.1.0	2013-06-30
jooq-meta	3.1.0	2013-06-30
jtds	1.3.0	2012-10-27
servlet-api	3.1	2013-04-25
play-json-joda	2.11-2.6.9	2018-03-01
lucene-core	4.10.0	2014-09-02
lucene-memory	4.10.0	2014-09-02
lucene-queries	4.10.0	2014-09-02
lucene-queryparser	4.10.0	2014-09-02
lucene-highilghter	4.10.0	2014-09-02
lucene-analyzers-common	4.10.0	2014-09-02
postgresql	9.2-1003-jdbc4	2013-05-27
jsoup	1.7.3	2013-11-11
jetty-util	9.2.5.v20141112	2014-11-12
tika-core	1.16	2017-07-07
commons-fileupload	1.3	2013-03-24
commons-beanutils	1.6	2005-11-08
commons-collections	2.1	2005-11-08
commons-digester	2.1	2010-09-24
commons-io	1.1	2005-11-24
commons-lang	1.0.1	2005-11-24
commons-logging	1.0.3	2005-11-17
commons-validator	1.0.2	2005-11-24
slf4j-api	1.6.4	2011-10-31
slf4j-nop	1.6.4	2011-10-31

JavaScript libraries

Software	Running	Release date
angular	1.2.11	2014-02-03
jQuery	1.10.2	2013-07-03
calendar	1.51	2005-03-07
calendar-setup	1.25	2005-03-07
fckeditor	2.6.11	2014-06-02
dom-drag	—	2001-10-28
jt_DialogBox	29	2012-08
jt_AppDialogs	9	2005-05
ng-grid	2.0.7	2013-06-07
ng-grid-flexible-height	2.0.7	2013-06-07
ng-grid.css	2.0.7	2013-06-07

Recommendations

Once the app’s software stack and libraries are up to date it’s important to regularly update. The complete upgrade experience can be a rigorous and involved process that includes juggling numerous issues and intensive testing.

From a client’s perspective, a major upgrade project often doesn’t obviously demonstrate improvement to appearance or function. Because it is not recommended to keep outdated software and major upgrades (such as the one described above) are tedious, the following update options are preferable in order to keep software libraries as up-to-date as possible:

Interval Based: Particular interval periods are implemented to check versions of software. This minimizes frequency of problems while ensuring a manageable gap between the current and latest software version.
Module Based: Whenever work is performed on any module for new features or bug fixes, software and library versions are reviewed. This allows for relevant libraries to be updated, tested, and deployed along with development changes within the module.

Conclusion

Even if new features and improvements are not pertinent to the new release, frequent upgrades to software and libraries are crucial in order to ensure the most secure and debugged versions. Please feel free to share your methods of managing software updates in a comment!

In-House to Consulting, Rinse and Repeat

2018-03-28T00:00:00+00:00

Photo by Matthew Henry of Burst

Hi! I’m Steph. I’ve been working 10+ years now as a software engineer, and I’ve spent ~4 years of that as an in-house developer at 2 different companies and 7+ years as a consultant here at End Point and as an independent contractor. Whenever I’ve started a new position, I get asked “What’s it like on the other side?” or something along the lines of “Is the grass greener?” I thought my answer to this was good blog fodder, so here we are.

If you google “in-house vs. consultant”, much of the results are written from the perspective of a company looking to hire either in-house engineers or looking to outsource to consulting companies. Here’s my approach to answer the question as it relates to employee happiness, skill development, and job satisfaction.

Working as an in-house engineer

Working as an in-house engineer can mean that you may focus on one technology (or one web stack) and even one main codebase, although this isn’t necessarily true. When I worked for Backcountry.com a while back, the main application was an ecommerce application running on Interchange, and that’s where I spent most of my dev time. But as my experience grew, I began working on other internal B2B tools as well.
With a small team, it’s possible you might adopt consistent style rules in the code.
In an engineering role as an in-house dev, you might not be directly involved in sales efforts of the company.
With a small, single team, there is only one set of team dynamics that you have to navigate between, which might allow you to build stronger relationships with those team members and understand how to work with those team members efficiently. Of course the disadvantage of this is if you don’t get along with a team member, you should learn how to work with them.
Working as an engineer for a product company might mean a steady stream of income and less micromanaging of expenses. This might translate to benefits like maternity leave, simply because the revenue stream can support paid leave, but this isn’t necessarily true and highly dependent on the circumstances. On the flip side, if the company isn’t doing well financially, there isn’t a resource for additional income, which could translate to loss of jobs for employees.
From my experience, working with a small team, there have been better processes in place for code review and code feedback, ultimately resulting in better growth of individual engineers. I have found that while I was an in-house engineer, I did a deep dive into one technology stack, and my skills greatly improved with that depth of experience.

Working as a consultant

Working as a consultant often offers the ability to be exposed to many technologies, many technology stacks, and more variety.
From my experience, adaptability is highly valued in the consulting space because you are exposed to different technology stacks and development processes. It is valuable to move seamlessly between teams and technologies.
Depending on how your company is set up, there can be a wide range of types of client interaction. Some clients want to learn how to make website changes and your role is to support them in that desire. Other clients may be hands-off all dev work, expecting you to have the expertise to drive technology choices. Clients may have very limited budgets and want a consultant to provide the most value to them. Client management is very important here.
In consulting, from my experience, it is not unusual to participate in sales efforts to provide estimates or technical solutions for proposals.
While I find many successful software engineering consultants have a breadth of knowledge, companies can often grow talent in specific areas or with specific hires to gain a depth of knowledge in specific technologies. The benefit to other employees is the access to expertise that may translate to better efficiency for clients (for example when I ping other expert co-workers when a question is not in my skillset).
By nature, consulting is diverse, so job stability may be decent if clients are overall successful and you are successful in working with them.

Working for a company that does both consulting and product development

I’ve seen a few companies that have been successful in both consulting and product development, where their employees develop a product but supplement company income with expert consulting.
From an employee perspective, this may offer a nice balance between breadth and depth in working on specific technology stacks.
A company that does both product development and consulting successfully may be more stable financially due to diversified income streams.

In-house & consulting

In both scenarios, I’ve found there is always a feedback loop going on in during active software development. You complete some task, pass it on for review, wait for feedback from a decision maker to iterate to the next step or adjustments. I like to fill in time when I’m waiting by working on another feature (in-house) or other client work (consulting).
My personal experience has taught me that communication is one of the most valuable assets to have as a software engineer, because you are responsible for translating business needs to software. The better you can communicate with intent, the more efficient you will be as an in-house engineer and as a consultant.
The ability to calculate work effort and manage priorities is also a highly valued skill in both employment circumstances.
From my own experience, I’ve been lucky to receive flexibility in both scenarios working half/part-time since my first daughter was born. In the consulting space, working limited time may be suitable for limited client budgets, but as an in-house engineer working half-time translated to less output while still providing knowledge from previous experience.
I’ve also found that in both scenarios, some job satisfaction comes from the happiness of the client (or decision maker), which can put you in a difficult position if your client isn’t happy. Every time the decision maker walks away dissatisfied, I think you have an opportunity to improve how to communicate and work with them to build a successful relationship.

Conclusion: Is the grass greener on the other side?

If you ask me “What’s the best option for me?”, I can’t answer that for you in your particular circumstances. I think an in-house position establishes a good foundation in a single set of technologies that could be beneficial as you progress in your career should you choose to climb the ladder in your current position or move to a consulting position. But if you are adaptable, and want to grow your breadth of experience and exposure to technologies, I think consulting is a good fit.

In true consulting form, I can only suggest to anyone considering a job change from one to another that you evaluate factors such as job satisfaction, compensation, flexibility, and stability when you are evaluating your options.

Reconciling Android source code

2017-12-19T00:00:00+00:00

Recently, a client came to us with an interesting problem. They needed some changes made to an internal-use Android app that had been created for them by another company, but they didn’t have up-to-date source code for the app, and they had no way of getting it. They gave us an old archive of source code, a more recent working build of the app, and asked us to figure it out.

The working version of the app they sent us was built in early 2016, and the app was compiled for Android SDK version 22, which is 5.1 Lollipop. It came out in March 2015, so it was a year old even when the app was created, and the code was using lots of features which have since been deprecated.

After putting this source code in a Git repository, I started by building the app from the source they’d sent and comparing it to the working version. It looked mostly the same, but a couple of features were broken. At the suggestion of a coworker, I used BytecodeViewer to decompile the APK and took a look around.

It was a little while before I was able to find any differences between the source we had and this decompiled code, but I did find a few logic differences. The source was also using a few old APIs that needed to be updated. With the needed changes made to the source code, I soon had a working build of the app that matched the functionality of the built APK we had.

This wasn’t the only thing wrong with the app, however. Another hurdle in picking up this project from its previous developers showed up when I had to fix a few odd problems reported by the users. One problem was on an information screen listing attributes of items. An example:

The “Quantity” field worked just fine for any non-zero value, but if it was 0, the app was displaying 16 instead. This turned out to be very simple to fix. Below is the layout code involved:

<TextView
    android:layout_width="wrap_content"
    android:layout_height="wrap_content"
    android:textAppearance="?android:attr/textAppearanceMedium"
    android:text="16"
    android:textColor="@color/background_black"
    android:id="@+id/txt_info_quantity" />

The default text of that field was, likely as a placeholder, set to 16, and it wasn’t being overwritten when the given value was 0. So, all I had to do was replace it with 0, since it would be overwritten anytime there was a nonzero value.

This was a good reminder to somehow keep track of placeholders like this, for example, putting a todo comment or something similar, so bugs like this can be caught in code reviews.

Figuring out how to reconcile the source and binary of this app seemed like a daunting task, but it turned out to be very doable, and was a very interesting project.