Foo Bar

Вам нужен типограф, а не spellchecker.
Есть от студии Лебедева с открытым API - https://www.artlebedev.ru/tools/typograf/webservice/

Или вот еще - typograf.ru (так же есть веб-сервис).

Если вас не устраиват веб-сервис, можно взять исходники (https://github.com/typograf/typograf.github.io/) или скачать библиотеку typus для python (описание на Хабре - https://habrahabr.ru/post/303608/).

Некоторые поддерживают проверку орфографии заодно, это как бонус :)

Тут вам нужно исходить из задачи (по вопросу она не до конца ясна).
Если у вас у одной компании одно или несколько расписаний, то через Foreign Key. При этом у всех компаний будут свои экземпляры расписаний.
А если вам нужно сделать так, что у нескольких компаний должно быть общее расписание, то... тоже Foreign Key в модели компании :)

ManyToMany - это связь многие к многим, т.е. когда "у вас вообще ничего не понятно" и любая компания может иметь либо свое расписание, либо чужое, либо и то и другое.

... если я конечно же правильно понял вопрос)

Мне кажется, что лучше везде расписать свои модели и связать их OneToOneField.
А в запросах выборок проверять видимость в одной из моделей, или же при обновлении в каждой модели актуализировать значение в главной таблице.

"Доверяй, но проверяй". И конечно же зависит от поставленных задач:

Если нужно быстро собрать работающий прототип, то приложения - хороший вариант.

Если же проект с долгосрочной перспективой и постоянным развитием, то все что можно заменить/переписать, мне кажется, стоит заменить своим кодом, чтобы лучше знать что и как работает и не зависеть от сторонней разработки.

Только без фанатизма. Есть хорошие и хорошо поддерживаемые приложений, разработка которых самостоятельным образом выльется в большие трудовые и финансовые затраты, поэтому не имеет особого смысла.

Для проверки решения существуют разного рода аудиторские конторы, сервисы и стандарты, которые и на безопасности проверят, и на нагрузку если нужно.

Есть замечательная книга "Two Scoops of Django 1.8" (best practices), легко гуглится. Книга не переведена на русский, но читается легко. В ней описаны практические решения выше обозначенных вопросов по организации проекта и много чего еще интересного и правильного.

А вообще, Django позволяет переорганизовать проект по удобной разработчику схеме и делается это достаточно просто.

Обычно я делаю вместо папки главного проекта - папку config (с файлом settings.py), так же идет общая папка с шаблонами (которые разбиты по приложениям), а логические части проекта разбиваю на приложениям.

Выглядит все примерно так:

./manage.py
./config/
./config/settings.py
./config/ursl.py
./templates/blog/
./templates/blog/base.html
./templates/blog/about.html
./templates/accounts/
./templates/accounts/login.html
./templates/accounts/registration.html
./acccounts/
./acccounts/urls.py
./acccounts/...
./blog/
./blog/urls.py
./blog/...

Но есть у меня проект, где только папка config, а все остальное - динамически создаваемый контент.

Приведу свой велосипед)

Во-первых, структуру можно упростить и универсализировать одновременно:

docs/
./intro1.md
./intro2.md
./chapter1/
./chapter1/part1.md
./chapter1/part2.md

Т.е. названия файлов - это названия страницы. Содержание по такой структуре можно построить просто как дерево файлов указанного каталога.

Во-вторых, используйте MarkDown синтаксис и расширение под Python. Простота в редактировании и легко и корректно конвертируется в html.

В-третьих, обрабатывается такая структура очень просто в Django:

urls.py

urlpatterns = patterns(
    '',
    url(r'^wiki/(.*)$', 'wiki.views.wiki', name='wiki'),
)

views.py

def wiki(request, page=None):
    if not page:
        page = 'main'
    file_name = os.path.join('.', 'wiki', page)
    file_name = ''.join((file_name, '.md'))
    input_file = codecs.open(file_name, mode="r", encoding="utf-8")
    text = input_file.read()
    input_file.close()
    content = markdown.markdown(text)
    context = {
        "wiki_content": content,
        "wiki_title": page
    }
    return render_to_response(
        'wiki.html',
        dirs=get_dirs(),
        dictionary=context,
        context_instance=RequestContext(request)
    )

и шаблон wiki.html:

<!DOCTYPE html>
<html>
<head>
	<title>{{ wiki_title }} - Wiki</title>
</head>
<body>
	<h1>{{ wiki_title }}</h1>
	<hr>
	<div class="content">
		{{ wiki_content|safe }}
	</div>
</body>
</html>